Re: Changing session timeout for a webapp via JMX or internal Tomcat API?
Thanks Igor. I made a mistake though. I actually meant "modifying web.xml and restarting the webapp." We want to find a way to change session timeouts - even for existing sessions - without doing a restart of the webapp. I know there's also a server-level session timeout in tomcat's /conf/web.xml but that would 1.affect all webapps (we only want to affect the older version - foo##001) and 2.it requires tomcat restart (we are trying to reduce downtime for users) Ellecer On Wednesday, November 30, 2011, Igor Cicimov wrote: >> >> >> > On Wed, Nov 30, 2011 at 4:11 PM, Ellecer Valencia wrote: > >> Is there a way to change session timeouts in tomcat via JMX? I've only >> seen the operation called "expireSession", but not one that can change >> the session timeout period. >> >> The only way I've found so far to modify session timeouts is by >> modifying web.xml and restarting Tomcat. >> >> However, in our intended usage, we don't want to restart Tomcat and >> kick out users. >> >> We're looking at using parallel deployment in Tomcat 7, and so we'll >> have a situation with >> >> foo##001 -- old version >> foo##002 -- new version >> >> What we want to do is decrease timeouts in foo##001, so that users >> move to foo##002 sooner and allow us to get rid of the old version. >> >> I've had a look at the Manager MBean and there's operations to get the >> existing session IDs and to expire individual sessions, but not to >> change their timeouts (unless I've gone blind and there was something >> there staring me in the face!). >> >> Is there any way - either another MBean in Tomcat or by accessing >> Tomcat API - to change the session timeouts for a webapp? Someone told >> me that Weblogic has this feature, so maybe it's not impossible to do >> it in Tomcat (just speculating) >> >> >> Ellecer >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > Can't you just restart the application you are changing the timeout for? > Why do you need to restart the whole server? >
Changing session timeout for a webapp via JMX or internal Tomcat API?
Is there a way to change session timeouts in tomcat via JMX? I've only seen the operation called "expireSession", but not one that can change the session timeout period. The only way I've found so far to modify session timeouts is by modifying web.xml and restarting Tomcat. However, in our intended usage, we don't want to restart Tomcat and kick out users. We're looking at using parallel deployment in Tomcat 7, and so we'll have a situation with foo##001 -- old version foo##002 -- new version What we want to do is decrease timeouts in foo##001, so that users move to foo##002 sooner and allow us to get rid of the old version. I've had a look at the Manager MBean and there's operations to get the existing session IDs and to expire individual sessions, but not to change their timeouts (unless I've gone blind and there was something there staring me in the face!). Is there any way - either another MBean in Tomcat or by accessing Tomcat API - to change the session timeouts for a webapp? Someone told me that Weblogic has this feature, so maybe it's not impossible to do it in Tomcat (just speculating) Ellecer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Parallel deployment - can we use JMX to monitor old and new versions of a webapp?
Hi, We're looking into the parallel deployment feature of Tomcat 7 and want to see if there is a way to monitor performance stats of an old deployment of a webapp. Our webapp has a few pages that display application-specific information - performance indicators, recent exceptions, cache information - and when the new version of a webapp is deployed, we still want to be able to monitor this info for the old webapp (eg, be able to view the monitoring info for both foo##001.war [old] and foo##002.war [new]) >From the testing we've done, it looks like the only way to be able to view a page in the older app after the new app is deployed is if we already have a session open on the old one. The admin interface is actually a set of iframes, with each iframe viewing a specified page on each of the machines in the cluster. The problem is if the browser crashes or is accidentally closed. Would using JMX allow us to view this information for the two webapp versions without being dependent on user sessions? How would we distinguish between status info coming from the old and new webapp versions? We haven't had experience using this before, so we're not too clear on what it allows us to do and what it entails. Yes, it sorta begs the question as to why we need to monitor an app that is being replaced anyway, and no longer accessible once existing sessions are closed. Anyway, we'd still like to know. =) In any case if it ends up being too much work then we'll just go with the first option. thanks, Ellecer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
Ah yes. Thanks Chuck. That makes more sense. =) On Mon, Oct 31, 2011 at 3:04 PM, Caldarale, Charles R wrote: >> From: Ellecer Valencia [mailto:elle...@gmail.com] >> Subject: Re: Rollback in Tomcat7 under parallel deployment > >> But how would it cause an outage? ROOT##003 would not necessarily be >> copied from the file ROOT##001.war > > I believe Chris was referring to your originally stated tactic of just > undeploying ROOT##002, rather than deploying a third version identical to the > first. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
Hi Chris, But how would it cause an outage? ROOT##003 would not necessarily be copied from the file ROOT##001.war It'll be a separate deployment, but just using the same build that got deployed as ROOT##001. Whether ROOT##001 is marked for undeployment should not make a difference to ROOT##003. They will "own" different sessions. Ellecer On Sat, Oct 29, 2011 at 7:53 AM, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ellecer, > > On 10/27/2011 7:11 PM, Ellecer Valencia wrote: >> On Thursday, October 27, 2011, Mark Thomas >> wrote: >>> A better way to handle the rollback scenario is to deploy a copy >>> of ROOT##001.war as ROOT#003.war. >> >> That's the first option we saw, but just wanted to confirm that >> there wasn't another rollback feature similar to parallel >> deployment. I guess in a rollback scenario it's probably more >> prudent to just end those sessions since the app is broken anyway. >> The idea of "parallel rollback" hurts my head just imagining how it >> would be implemented! =) > > I might be worried that ROOT##001 had been marked for > eventual-undeployment and you might find yourself in a situation where > your "rollback" essentially causes an outage. > > Mark, can you confirm the behavior in this situation? The (brief) > documentation says that the "latest version" will be used if a session > does not yet exist. Is the "latest version" defined as the highest > version number yet deployed (in which case the above scenario will > occur) or is it defined as the highest version number currently deployed? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6rFkEACgkQ9CaO5/Lv0PBR9ACghJGnUy7tSYzmo7MJNA73eWsZ > GYAAnR/7fvwFtzeFRcnhhouAW88VOrBX > =zn6f > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rollback in Tomcat7 under parallel deployment
On Thursday, October 27, 2011, Mark Thomas wrote: >> Also, what happens if ROOT##001 and ##002 have the same log4j configs >> and are writing to the same log file?? How have people handled this >> situation? > > You'll certainly end up with both apps writing to the same file. Whether > or not that is a problem will depend on exactly how you have configured > logging. See [1] for other things to think about. Looks like it's something that shouldn't be allowed to occur, at least under log4j. http://logging.apache.org/log4j/1.2/manual.html "... image of the log4j environment will act independetly and without any mutual synchronization. For example, FileAppenders defined exactly the same way in multiple web-application configurations will all attempt to write the same file. The results are likely to be less than satisfactory. You must make sure that log4j configurations of different web-applications do not use the same underlying system resource." Logback supports writing to the same file, but at the cost of 3x slower performance: http://logback.qos.ch/manual/appenders.html#prudent But that entails even more changes in our code, so we'll have to have a workaround. (i guess we could replace log4j.jar with log4j-over-slf4j.jar then use logback! http://www.slf4j.org/legacy.html) >> thanks for you help, > > A better way to handle the rollback scenario is to deploy a copy of > ROOT##001.war as ROOT#003.war. That's the first option we saw, but just wanted to confirm that there wasn't another rollback feature similar to parallel deployment. I guess in a rollback scenario it's probably more prudent to just end those sessions since the app is broken anyway. The idea of "parallel rollback" hurts my head just imagining how it would be implemented! =) Ellecer > > Mark > > [1] http://java-monitor.com/forum/showthread.php?t=1288
Rollback in Tomcat7 under parallel deployment
Hi, If I'm using parallel deployment in Tomcat 7, and now have 2 webapps /webapps/ROOT##001.war /webapps/ROOT##002.war and then get problems in the new version and want to rollback to ROOT##001.war. If I delete the more recent version by doing rm /tomcat/webapps/ROOT##002.war What happens to the sessions that are being serviced by #002 once the file is removed? Will #002 still be around to service these sessions expire, or does Tomcat remove all these sessions instantly? Also, what happens if ROOT##001 and ##002 have the same log4j configs and are writing to the same log file?? How have people handled this situation? thanks for you help, Ellecer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
