Hi Hans, Thanks for your feedback, lb is high on my list as well. I hope to finish the first part of the refactoring next week, and then we can start with new features and good stuff like you mention.
I'm also trying to find a way to add/remove webapps without having to restart apache. Costin On Fri, 30 Nov 2001, Hans Schmid wrote: > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
