Hi, since Costin is currently refactoring mod_jk in jakarta-tomcat-connectors I want to throw in our usage scenario.
We are abusing the loadbalancing feature of mod_jk to switch tomcats on the fly in order to be able to make application updates without killing our curreent user sessions. See discussion below from tomcat-user This feature (graceful restart) was present in jserv and is still missing in mod_jk/Tomcat3.3 as far as I know. Below are references to the archive where Michael Kuz has sent a patch to decouple this feature from the lbfactor (introducing an active flag). So please keep in mind the requirement to be able to update Webapps in a farm of Tomcats without killing active sessions. Thanks, Hans -----Ursprüngliche Nachricht----- Von: Hans Schmid [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 28. November 2001 18:21 An: Tomcat Users List Betreff: AW: TC3.3 updating a webapp without killing sessions Thanks Larry, perhaps a lbfactor of 0.00001 or so would do the job for us. We could probably live with 1 out of 100000 sessions beeing sent to the wrong Tomcat and beeing killed if this instance shuts down. Should this be discussed in tomcat-dev ? I remember a patch from early this year which tried to fix this (check the archives) but did never make it into the release It tried to add a flag called 'active' in the worker.properties file for each worker instead of misusing the lbfactor for this. ajp13-01... lbfactor=1 active=0 and ajb13-02... lbfactor=1 active=1 see http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00102.html and http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00114.html for the patch which might be a little bit outdated > -----Ursprüngliche Nachricht----- > Von: Larry Isaacs [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 28. November 2001 15:00 > An: 'Tomcat Users List' > Betreff: RE: TC3.3 updating a webapp without killing sessions > > > I assume the value or lbfactor is requested to be >0 > because 1/lbfactor is calculated during initialization. > Since this is done with doubles, it may generate an > internal representation for infinity rather than a division > by zero error. > > I don't have a complete understanding of what mod_jk > does internally for loadbalancing, but your approach > seems like it should work. A brief scan of the codes > shows that some updates to mod_jk would be needed > to insure that lbfactor=0 means only use this worker > when mandated by session routing. > > There isn't much logging around the choice of worker. > Perhaps adding some logging would help determine > why requests are being routed to the lbfactor=0 > Tomcat when session routing shouldn't be a factor. > > Hope this helps. > > Cheers, > Larry > > > > -----Original Message----- > > From: Hans Schmid [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, November 28, 2001 4:25 AM > > To: Tomcat-User > > Subject: TC3.3 updating a webapp without killing sessions > > > > > > Hi, > > > > We try to make a workaround for the following problems: > > 1.) memory management > > 2.) application update > > 3.) do not kill active sessions > > > > Perhaps someone can comment on the startegy and answer some questions. > > > > > > Our environment: > > Tomcat 3.3 final with mod_jk Apache 1.3.19 on Solaris 2.7 Sparc > > > > Our problem: > > ever growing cache until memory runs out (clearly an > > application problem) > > plus soft updates to our application without killing actiove sessions > > > > The idea: > > when a certain ammount of memory is reached by the tomcat > > java process, > > start up a second > > Tomcat and route all new requests to the second instance > > while existing > > sessions should phase out > > on the first instance. > > If no more sessions are active on the original Tomcat, shut it down > > (currently we just shut it down 30 minutes after the second > > Tomcat started > > up) > > > > How to do it with mod_jk: > > We have two versions of a worker.properties. Before we start > > up our second > > tomcat, > > we switch a link to point to the other version. > > > > Both versions of the worker.property file have a loadbalancer worker > > defined: > > > > First version: > > worker.list=loadbalancer > > > > worker.ajp13-01.port=11009 > > worker.ajp13-01.host=tomcathost > > worker.ajp13-01.type=ajp13 > > worker.ajp13-01.lbfactor=1 <- important > > > > worker.ajp13-02.port=11019 > > worker.ajp13-02.host=tomcathost > > worker.ajp13-02.type=ajp13 > > worker.ajp13-02.lbfactor=0 <- important > > > > worker.loadbalancer.type=lb > > worker.loadbalancer.balanced_workers=ajp13-01, ajp13-02 > > > > Second version: > > worker.list=loadbalancer > > > > worker.ajp13-01.port=11009 > > worker.ajp13-01.host=tomcathost > > worker.ajp13-01.type=ajp13 > > worker.ajp13-01.lbfactor=0 <- important > > > > worker.ajp13-02.port=11019 > > worker.ajp13-02.host=tomcathost > > worker.ajp13-02.type=ajp13 > > worker.ajp13-02.lbfactor=1 <- important > > > > worker.loadbalancer.type=lb > > worker.loadbalancer.balanced_workers=ajp13-02, ajp13-01 > > > > > > We just try to switch the lbfactor from 1 to 0 for the first Tomcat > > and from 0 to 1 for the second Tomcat. > > after the switch we do a graceful restart of apache. > > > > > > but after this we still see new sessions beeing created on > > the first Tomcat > > now with lbfactor=0! > > Why? > > > > Question: why does it state in the workers.properties that > > lbfactor must be > > > 0 ? > > should we set it to 0.000001 instead of 0? > > > > Is this strategy completely nuts? > > Is there a better way to accomplish this? > > > > > > And yes, we need to fix our caching strategy ... but ... > > > > Best regards, > > Hans > > > > > > -- > > To unsubscribe: <mailto:[EMAIL PROTECTED]> > > For additional commands: <mailto:[EMAIL PROTECTED]> > > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
