Thanks, Mladen, as long as this disabled feature does not prevent the failover case, I am fine ;)
See inline ... > -----Ursprüngliche Nachricht----- > Von: Mladen Turk [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 18. Februar 2005 10:36 > An: Tomcat Developers List > Betreff: Re: AW: mod_jk release policy - was: JK 1.2.9-dev test results > > > Hans Schmid wrote: > > Hi, > > > > I just want to describe our usecase because we make heavy use of the > > local_worker and local_worker_only flags right now. > > > > > > We use those flags for 'maintenance' mode and failover very successfuly. > > > > Cool ;). > > > > But please see our setup and usecase below. > > > > We only use one tomcat at a time to get traffic with a standby tomcat for > > maineneance. > > This scenario also covers failover. We do not use the loadbalancer to > > actually balance > > by factors. > > > > OK. So basically you have two tomcat boxes where the second is used > only when you wish to put the first on maintenance? Both Tomcats are always running, but the second one is used only for: 1.) Failover 2.) Maintenance switch -> after this the roles of both Tomcats have switched (TC-01 becomes standby) In fact our scenario is a little bit more complex (I just did not want to explain it in the first place). This brings in Loadbalancing as well: We actually have between 3 and 6 Tomcats running at the same time depending on our load, which has high seasonal peeks. So November is usually 20 times as much as February. We are talking about 500 concurrent users in our webapp plus many more on the static apache pages. Example: 4 Tomcats are running in parallel. Just TC-01 has local_worker=1, the other ones have local_worker=0. Every 30 minutes we switch our worker.properties to activate a different tomcat by setting its local_worker=1 and the old one to 0. The new tomcat has been just restarted before. TC-01 -> 30min. -> TC-02 -> 30min. -> TC-03 -> 30min. -> TC-04 -> 30min. -> TC-01 again .... That way, every Tomcat gets new sessions for about 30 minutes. The long lasting ols sticky sessions of our users (avg. session time 30min.) stay active on the Tomcat which was active before for the rest of their live. This effectively generates a loadbalancing distribution of about TC-01 = 55% (the currently active Tomcat) TC-04 = 35% (the one which was active before but still handles sticky sessions) TC-03 <= 10% (the one before TC-04, handling really long lasting old sessions) TC-02 = 0% (this one is the next candidate to restart and become active) We can easily scale this approach by bringing in even more tomcats and shorter roll times (or less and longer times). Works really well with our highly changing but well known traffic ;) (and handles memory leaks as well ...) Cheers Hans > > Using new config: > > worker.list=loadbalancer > worker.loadbalancer.balanced_workers=ajp13-01,ajp13-02 > worker.loadbalancer.sticky_session=True > > worker.ajp13-01.disabled=0 > ... > worker.ajp13-02.disabled=1 > > > Disabled flag initially mark the worker as disabled. > It will not be used until: > > Use the jkstatus console and set the: > worker.ajp13-02.disabled=0 > and > worker.ajp13-01.disabled=1 > > And that's it. > Existing sessions will be forwarded to ajp13-01, > while new will go to the ajp13-02. > No need to make tricks with symlnks, graceful restarts, etc. > What's more, it works on all platforms and all web servers. > > > Also take a look at: > http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html > (Big red warning about worker names) > > Regards, > Mladen. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
