Mailing List Archive

On Fri, Dec 14, 2001 at 07:18:30PM -0000, Glenn Grimes wrote:
> I was wondering if anyone has reverted to the automatic reconnection and if
> so do they have a patch file that I could use as I would like/need conserver
> to log what is going on during the boot process etc.

I'm hearing more and more about this issue. I'd really like to find a
nice way for conserver to try and reopen the lines once or maybe twice
and then fallback to shutting things down, but I haven't put enough
thought into the code. For those that would like to get the old
behavior back (well, something close to the old behavior), look at line
799 of conserver/group.c. You'll see:

/*ConsInit(pCEServing, &rinit, 0); */
ConsDown(pCEServing, &rinit);

Just comment out the ConsDown and uncomment the ConsInit...

ConsInit(pCEServing, &rinit, 0);
/*ConsDown(pCEServing, &rinit);*/

I'm beginning to believe that the ConsInit is the right thing to do and
that the number of folks experiencing the random high load/respawn
problem is very small compared to the number of folks that would
benefit from automatically reconnecting on a disconnect.

Bryan

On 2001-12-15 at 01:16, Bryan Stansell (bryan@conserver.com) wrote:

> I'm beginning to believe that the ConsInit is the right thing to do and
> that the number of folks experiencing the random high load/respawn
> problem is very small compared to the number of folks that would
> benefit from automatically reconnecting on a disconnect.

Probably true. How about having it try to reconnect once a minute
(sleep 60 between retries). That way, it will try to reconnect, but
won't get into a tight resource-hogging loop.

The problem with using a sleep() in the code is that the process does
just that - it sleeps. Each process is managing 16 consoles (by
default) and if it sleeps, all activity for those 16 consoles and
anyone connected to any of those consoles stops for the length of the
sleep(). So, just putting a sleep in there doesn't work well. There
is a timer that goes off every minute that's used to produce the
timestamps in the logfiles. It should be possible to use that
mechanism, but, again, I haven't put much thought into the impact of
inserting code there either.

So, yep, should be possible. Hmm...maybe it would be as simple as
putting it in the timer loop. I guess the only other bit I'd like to
see is a counter of auto-retries and if that hits two or three, it
stops trying to reconnect. But, that should be easy as well.
Hmm...I'm feeling inspired... :-)

Bryan

On Sat, Dec 15, 2001 at 12:05:45PM -0800, Jim Gottlieb wrote:
> On 2001-12-15 at 01:16, Bryan Stansell (bryan@conserver.com) wrote:
>
> > I'm beginning to believe that the ConsInit is the right thing to do and
> > that the number of folks experiencing the random high load/respawn
> > problem is very small compared to the number of folks that would
> > benefit from automatically reconnecting on a disconnect.
>
> Probably true. How about having it try to reconnect once a minute
> (sleep 60 between retries). That way, it will try to reconnect, but
> won't get into a tight resource-hogging loop.
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users

On Sat, 15 Dec 2001, Bryan Stansell wrote:

> The problem with using a sleep() in the code is that the process does
> just that - it sleeps. Each process is managing 16 consoles (by
> default) and if it sleeps, all activity for those 16 consoles and
> anyone connected to any of those consoles stops for the length of the
> sleep(). So, just putting a sleep in there doesn't work well. There
> is a timer that goes off every minute that's used to produce the
> timestamps in the logfiles. It should be possible to use that
> mechanism, but, again, I haven't put much thought into the impact of
> inserting code there either.
>
> So, yep, should be possible. Hmm...maybe it would be as simple as
> putting it in the timer loop. I guess the only other bit I'd like to
> see is a counter of auto-retries and if that hits two or three, it
> stops trying to reconnect. But, that should be easy as well.
> Hmm...I'm feeling inspired... :-)
>

yeah, like ntp. it has an alarm every so often and goes through
an array of pointers. null pointers ignored, pointers pointing
to something are checked. You could do the same thing with stuck
consoles, add them to a linked list or array or something like that
that gets checked every so often.

Back to lurking. ;)