Hi,
On Fri, Jan 26, 2001 at 01:27:09PM -0500, ext Dan Milstein wrote:
>
> 3) Restarting Apache == Bad
>
> Makes sense to me. Anyone else?
>
I guess it depends on how well apache handles a restart. Are any
current browser connections broken or will apache serv every open
connection first and then restart so that even under heavy load it
will not be noticed by browsers?
> A heartbeat would be a nice addition -- however, in the case of the specific
> functionality requested (stopping new sessions from going to a TC instance),
> you still need to somehow let an administrator tell the system to stop using
> that instance for *new* sessions (while still sending current ones there).
> The instance is functioning fine, but you decide proactively that you'll
> want to shut it down soon. So you (the admin) somehow need to tell the
> lb_worker to move that instance onto a special list.
>
> Michael's code does a nice job of handling that "special list" -- he sets up
> a new flag for the workers being managed by the lb_workers, and does all the
> right things in terms of not sending new sessions, etc.
>
> If we don't restart Apache, does anyone have any grand ideas about how to
> communicate to the mod_jk plugin that it should shift a particular worker
> into this state? We could put it on the TC side, but then we'd have to
> modify all the protocols to communicate back to the plugin that they should
> no longer get new sessions. That seems tricky to me. Or maybe the
> lb_worker should open up an out-of-band communication channel with TC? That
> would be nice, because it could then control all of the workers, regardless
> of protocol. Opinions?
>
> Can anyone comment on how hard/easy this would be to do entirely on the
> Apache side?
>
This is how it works in mod_jserv: The state of the tomcat engines are
kept in shared memory. All httpd processes in one machine use this
same shared memory. This way when one httpd find a tomcat process dead
all the other knows about this too and don't spend time doing
unnecessary connections.
The shared memory can then also be written by another "admin" process
that can set the state of one tomcat engine to SHUTDOWN_GRACEFULLY or
SHUTDOWN_IMMEDIATE. This way everything is handled on the apache side
and no communication between the tomcat process and apache is
needed. The drawback is of course that the administrator has to set
the state in the shared memory on all machines running apache
connecting to the tomcat engine being shut down. Just telling it to
the tomcat process and the apache processes finding it out from there
would be better I guess.
mod_jserv also starts a watchdog process that monitors the state in
the shared memory and tries if processes in the DOWN state would be UP
now. The difference from mod_jk is that the testing is not done in the
process of a request for a page so if checking takes a long time the
user doesn't have to know about it.
As far as I can tell the code for the shared memory handling and the
watchdog process would be usable in mod_jk with some small changes but
I haven't done any actual work on apache modules so this is not an
expert opinion.
Stefan Åberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
