Hi Thomas, Thomas Glanzmann schrieb:
Hello, I have mod_jk version 1:1.2.18-3etch1 (which comes with Debian Etch) as loadbalancer in front of four tomcats version 5.5.20-2etch2 that do not duplicate sessions because of their size (100Mbyte per session; 120 - 500 users). My workers.property looks the following:worker.list=router, jkstatus worker.router.type=lb worker.router.balance_workers=tomcat-01, tomcat-02, tomcat-03, tomcat-04 worker.tomcat-01.type=ajp13 worker.tomcat-01.host=tomcat-01 worker.tomcat-01.port=8009 worker.tomcat-01.lbfactor=1 worker.tomcat-02.type=ajp13 worker.tomcat-02.host=tomcat-02 worker.tomcat-02.port=8009 worker.tomcat-02.lbfactor=1 worker.tomcat-03.type=ajp13 worker.tomcat-03.host=tomcat-03 worker.tomcat-03.port=8009 worker.tomcat-03.lbfactor=1 worker.tomcat-04.type=ajp13 worker.tomcat-04.host=tomcat-04 worker.tomcat-04.port=8009 worker.tomcat-04.lbfactor=2 worker.jkstatus.type=status I have to schedule once a week a software update, so I have to take a tomcat server offline to upgrade the software. The problem is that I don't want to kick any users. So I switch in jk_status the mode to disabled. This works for most of the users. After their session times out, they're gone. But I have a few sticky users, who leave their browser open (and come back after 4 hours or a day) or bookmark a site that contains a session id. Mod jk sees the session id and directs it to the disabled tomcat. On the tomcat itself the session id is invalid, it generates a new one and I have the user back on my disabled tomcat. Duplicating the session to another tomcat is currently not possible because a single session has around 100 Mbyte and even in off-hours like right now, there are 100 active sessions. How do other people handle this problem? Is there a way to make mod_jk to check if the session is still active on the tomcat (maybe with a newer version) and only puts a session to a disabled tomcat if indeed the session is still active on that tomcat? Thomas
No, the design of mod_jk is stateless w.r.t. sessions. There are only the obvious solutions, i.e. assuming that after some time of disabling (time depending on typical session use cases like 10 minutes or an hour) you stop the worker and thereby redirect users that still try to use the node to another node. They'll get an error of course and would need to relogin.
Usually with some time of disable status you can reduce the number of sessions, that will need to relogin and thus be disturbed by your maintenance to about 5% (your mileage may vary).
If you want to improve user experience more, you could include a maintenance information in your app, like "Please logout and relogin during the next hour because we have a maintenance scheduled starting at ...".
Regards, Rainer --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
