You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by St...@nokia.com on 2001/01/26 11:12:24 UTC

jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Hi,

are there any plans to add the functionality found in mod_jserv for
managing high availability with load balancing? Secifically the
shutdown functionality seems to be missing where you could take one
tomcat off the load balancing pool and still send old sessions there
for a while.

Checking the code it would seem that the functionality from jserv_mmap.c
and jserv_watchdog.c would need to be added to mod_jk and then
jk_lb_worker.c
would need to be changed a bit. Are there any forseeable problems with doing
this?

Maybe is something else planned to improve the high availability features of
mod_jk in the direction of what mod_jserv has or maybe something better?
If there is'nt I'll try to use the code from mod_jserv and see what comes of
it.

BR,
Stefan Åberg

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Posted by Dan Milstein <da...@shore.net>.
Thom May wrote:
> I posted a patch against the workers howto to the list a week or so ago, but
> I'd love to help with documentation.

Sorry that it took me a while to get around to applying that patch.  Any
help with the documentation would be great.  I don't have the best sense of
how much of it is still accurate (it sounds like maybe you've been testing
that, which would be doubly great).  One particularly important thing is to
clearly document any differences between 3.2 and the jakarta-tomcat HEAD
(aka 3.3).  In fact, if you do find any such (undocumented) differences, let
me (and the list) know -- maybe we can find a way to eliminate some of them.

Thanks,
-Dan

p.s. I have to say that promising to help with documentation is a very
effective way to get an old patch applied ;-)
-- 

Dan Milstein // danmil@shore.net

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Posted by Thom May <th...@amxstudios.com>.
* Dan Milstein (danmil@shore.net) wrote on Fri Jan 26, 2001 at 01:27:09 -0500:
> Thom,
> 
> Thanks for the feedback.  
> 
> 1) The mod_jk howto / vhosts
> 
> The mod_jk user docs are (as far as I can tell) kind of a mess.  I have a
> medium-term goal of overhauling them and cleaning them up, but I haven't
> done so yet.  I'm not clear on what they say about vhosts, and, to be
> honest, I'm no major expert on vhost configuration.  I'll try to take a look
> at this when I get a chance -- could you maybe send me the following:
> 
>  - A piece of a sample vhost config / mod_jk config which "should" work.
> 
>  - The specs for the system where it's currently not working.  Specifically:
> Apache version, TC version, connector protocol (e.g. ajp12, ajp13).
> 
> That would be very, very helpful.
OK, i'll get those to you on monday am - right now it's 18:45 Friday
evening, and the pub is beckoning :-)
I posted a patch against the workers howto to the list a week or so ago, but
I'd love to help with documentation.
> 
> 
> 2) Word-wrapping
> 
> <RED-FACED WITH SHAME>Thanks for pointing this out -- I had totally
> forgotten that I had this set this way.</SHAME>  Hopefully I have now fixed
> that.
Heh :) looks good to me.
> 
> 3) Restarting Apache == Bad
> 
> Makes sense to me.  Anyone else?  
> 
> 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.
OK, that makes sense.
> 
> 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?
I think that a solution that ends up with the load balancer controlling the
other workers is the ideal solution - and out of band communication sounds
like a pretty nice way of achieving that.
> 
> Can anyone comment on how hard/easy this would be to do entirely on the
> Apache side? 
> 
> -Dan
> 

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Posted by Thom May <th...@amxstudios.com>.
* Dan Milstein (danmil@shore.net) wrote on Fri Jan 26, 2001 at 01:27:09PM -0500:
> Thom,
> 
> Thanks for the feedback.  
> 
> 1) The mod_jk howto / vhosts
> 
> The mod_jk user docs are (as far as I can tell) kind of a mess.  I have a
> medium-term goal of overhauling them and cleaning them up, but I haven't
> done so yet.  I'm not clear on what they say about vhosts, and, to be
> honest, I'm no major expert on vhost configuration.  I'll try to take a look
> at this when I get a chance -- could you maybe send me the following:
> 
>  - A piece of a sample vhost config / mod_jk config which "should" work.
> 
>  - The specs for the system where it's currently not working.  Specifically:
> Apache version, TC version, connector protocol (e.g. ajp12, ajp13).
> 
> That would be very, very helpful.
OK. here's where I wind up looking like an idiot when I've fucked up my
config :P
httpd.conf first:
--snipped module loading stuff--

JkWorkersFile  /var/tomcat/conf/workers.properties
JKLogFile /var/tomcat/logs/mod_jk.log

--Snipped loads of default cruft --

<VirtualHost 192.168.3.27>
(setup stuff which I don't particularily want world+dog to see :) )
JkMount /servlets/* ajpv13
#ApJServMount /servlet ajpv12://localhost:8007/servlet
</VirtualHost>

then server.xml:
 <Host name="192.168.3.27">
         <Context path="/servlets/"
	 docBase="/data/www/virtual/xxxx/servlets/"
	 debug="0" reloadable="true" />
 </Host>

This is all the howto says you need to do.
Tomcat creates the context 192.168.3.27:/servlets/ and is listening on it.
However, mod_jk never sets up a handler for anything inside a VirtualHost
command.

Server: Apache/1.3.12 (Unix)  (Red Hat/Linux) PHP/3.0.12 mod_perl/1.21
mod_jk
Tomcat 3.2.1, ajp13.
cheers
-Thom

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Posted by stefan aberg <st...@nokia.com>.
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


Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Posted by Dan Milstein <da...@shore.net>.
Thom,

Thanks for the feedback.  

1) The mod_jk howto / vhosts

The mod_jk user docs are (as far as I can tell) kind of a mess.  I have a
medium-term goal of overhauling them and cleaning them up, but I haven't
done so yet.  I'm not clear on what they say about vhosts, and, to be
honest, I'm no major expert on vhost configuration.  I'll try to take a look
at this when I get a chance -- could you maybe send me the following:

 - A piece of a sample vhost config / mod_jk config which "should" work.

 - The specs for the system where it's currently not working.  Specifically:
Apache version, TC version, connector protocol (e.g. ajp12, ajp13).

That would be very, very helpful.


2) Word-wrapping

<RED-FACED WITH SHAME>Thanks for pointing this out -- I had totally
forgotten that I had this set this way.</SHAME>  Hopefully I have now fixed
that.


3) Restarting Apache == Bad

Makes sense to me.  Anyone else?  

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? 

-Dan

-- 

Dan Milstein // danmil@shore.net

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Posted by Thom May <th...@amxstudios.com>.
Hi Dan.
I really appreciate the work you're doing on Apache -> Tomcat connectivity!
Couple of questions first:

1) (totally unrelated) the mod_jk howto seems to suggest that mod_jk is
useable from _inside_
apache VirtualHost statements. However, practical experience - ands much
screaming ;) - have proven that this doesn't actually work, and any JkMount 
commands inside a VirtualHost are effectively ignored, even though tomcat
has created a vhost context on startup. do you know anything about this
functioanlity, and whether it could be implemented?

2) please could you investigate word wrapping your mails at 80 characters? 
(Mailing list readability etc :)  )

* Dan Milstein (danmil@shore.net) wrote on Fri Jan 26, 2001 at 11:29:58AM -0500:
> Stefan,
> 
> Michael Kuz actually submitted a nice patch to do just this, which I've 
> been intending to apply.  The only thing which has held me back is that
> you have to restart apache to let it know that it should stop sending
> new sessions to a particular TC instance.
> 
> Since you're interested in this area, can I ask you (and anyone else 
> interested) two questions:
> 
>  1) Do you think restarting apache is a problem?

Yes, given the point is for a HA web service. Tomcat already requires apache
to be shutdown far too much - everytime tomcat gets restarted apache has to
too - there must be a better way of implementing this. The front end web
server shouldn't see anything past the loadbalancing worker, which should
then manage the actual tomcat instances.Would it be possible to implement a
heartbeat style system for automatically taking dead or stopped instances
out of the pool?
There shouldn't be any need to restart apache.

>  2) Did the jserv code require restarting apache?

Not as far as I can remember.
> Thanks,
> -Dan
thanks again for all your efforts Dan,
cheers,
-Thom

Re: jserv SHUTDOWN_GRACEFULLY functionality with mod_jk?

Posted by Dan Milstein <da...@shore.net>.
Stefan,

Michael Kuz actually submitted a nice patch to do just this, which I've been intending to apply.  The only thing which has held me back is that you have to restart apache to let it know that it should stop sending new sessions to a particular TC instance.

Since you're interested in this area, can I ask you (and anyone else interested) two questions:

 1) Do you think restarting apache is a problem?
  
 2) Did the jserv code require restarting apache?

Thanks,
-Dan


Stefan.Aberg@nokia.com wrote:
> 
> Hi,
> 
> are there any plans to add the functionality found in mod_jserv for
> managing high availability with load balancing? Secifically the
> shutdown functionality seems to be missing where you could take one
> tomcat off the load balancing pool and still send old sessions there
> for a while.
> 
> Checking the code it would seem that the functionality from jserv_mmap.c
> and jserv_watchdog.c would need to be added to mod_jk and then
> jk_lb_worker.c
> would need to be changed a bit. Are there any forseeable problems with doing
> this?
> 
> Maybe is something else planned to improve the high availability features of
> mod_jk in the direction of what mod_jserv has or maybe something better?
> If there is'nt I'll try to use the code from mod_jserv and see what comes of
> it.
> 
> BR,
> Stefan Åberg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org

-- 

Dan Milstein // danmil@shore.net