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]>

Reply via email to