-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aristedes,
On 2/23/12 4:29 AM, Aristedes Maniatis wrote: > Given that we've definitely seen this happen with our sessionless > application, I'm not sure that will help us much. For our other > apps which have sessions, what happens if the incoming cookie > references a session which has expired? Will the connection be > simply handled by the new application? Yes. > Is there some chance that the old application then creates a new > valid session for that connection? I suppose there is some chance (there could be a bug) bu I suspect something else is going on. Is it possible that some component you aren't expecting is in fact creating a session that is otherwise unused? Adding the session id to the logger would certainly shed some light on that. > What we did do is add a version to our log4j logger so that we > could see which application was handling requests. We got quite a > mixture of requests to the older sessionless application. That's interesting. Please confirm that the requests do not have any session id associated with them. > Is there a task I can follow? I was unable to find one. If you'd like, you can file an enhancement request in Bugzilla. I wasn't able to find anything anything that already existed. https://issues.apache.org/bugzilla >>> We have been thinking about writing an external application to >>> poll using JMX and do this, but that's quite a bit of work. It >>> would be nicer if this happened inside tomcat itself. >> >> Agreed. Patches welcome. > > Sure. I understand, but I would not know where to begin with the > tomcat codebase. I haven't even tried to read the source at this > point. I assume we'd need to hook into some listener that detects > when sessions are terminated and tell when they reach zero. That is > maybe one line of code in the right place... or not :-) I haven't looked at the code closely enough to know if this would all work, but it seems reasonable that you could do the following: 1. Modify the parallel deployment code to register an MBean NotificationListener that filters for useful events (such as expiring session notifications on the outgoing webapp). 2. When the listener receives a notification, check the current state (e.g. session count=0; or, I suppose you could make this a part of your filter in step #1). If session count = 0, start a new thread that stops the outgoing webapp and de-registers the listener. Or. 1. Install a SessionEventListener that counts-down the sessions (you'll have to get the count from JMX, I suppose) until they equal 0, then starts a new thread that ... etc. Or. 1. Install a Timer thread that polls at intervals (1 minute?) to see if all the sessions are dead and then starts a thread ... etc. The first idea seems the cleanest, though Tomcat might not actually fire MBean events for things like session count changing. Again, I haven't checked the code myself, yet. >>> 3. Is there some resource we might be hanging onto which is >>> preventing the old application from properly stopping? >> >> Maybe. But that would be a separate issue. > > I am just looking for solutions within the particular stack that we > are using (tapestry/cayenne) to see if there was some reason why > tomcat wasn't fully letting go of the older application. If there are pending sessions, Tomcat shouldn't terminate that webapp. As previously mentioned, Tomcat will not (yet) auto-undeploy the old version when all sessions have terminated. >>> 4. Should the tomcat manager show the older apps as still >>> running or should they be shown as stopped? >> >> running. > > It would be nice if it showed as "disabled" (to use the mod_jk > terminology for an instance which is running but gets no new > sessions). It's just a coincidence that no new sessions are being created -- because sessionless requests /should/ be sent to the new version. The old version simply isn't used any more... it's not actually in any different state than the new version. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9K9JQACgkQ9CaO5/Lv0PAsDACgmH786rjCWgaQgCWy3L2HjoMp 0w4An12U6AuWEytXy2qzwAMWqsWG6vSQ =LeiA -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
