-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robin,
On 1/12/2010 5:19 PM, Robin Wilson wrote: > Your point is well taken about not creating the short-duration > sessions, but alas, Tapestry is the chosen framework - and it uses > the session as a mechanism to pass (more-or-less) "global" values > between components of the page creation process. So ripping out that > capability in Tapestry would require a massive change to our > infrastructure. I know virtualy nothing about Tapestry, but this page (http://tapestry.apache.org/tapestry4.1/usersguide/state.html) has the following nugget: " Tapestry defers creation of the HttpSession until one of two things happens: When a session-scoped application state object is first created, or when the first persistent page property is recorded. At this point, Tapestry will create the HttpSession to hold the object or property. " This would seem to indicate that you do have some control over the creation of sessions: by avoiding session-scoped application state objects and persistent page properties, you ought to avoid session creation. Another option would be to enable session stickiness and disable session replication: this improves performance across the board, while inconveniencing anyone who happens to have been using a server that gets failed-over to another server. > Your notes on the clustering (changes to DeltaManager) are right on > target. So we adjusted when the DeltaManager "creates" the session > until the end of processing, so that we know the timeout before we > attempt to replicate it to other cluster members. That way, we > already know the actual timeout duration before we decide whether to > replicate. Sounds good. > All of this would be unnecessary if there was some sort of "session > cleanup" process that could dump expired sessions "en masse" every so > often. Near as we can tell, each session has to be individually > expired, which is why it lags so far behind the creation process. You can always call session.invalidate() on a session that you already know will be useless. You could even do this in a Filter: any session that is worth keeping around could contain a key like KEEP_ME. If that flag exists, then allow the DeltaManager to replicate the session. Otherwise, call invalidate() and kill the session immediately. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktN4OoACgkQ9CaO5/Lv0PC4MQCdFG4J4jCfNhcapr4sb7+cA9k2 lXEAoJ8wOKpSdF9hTcbag6tZPibgVKvp =ywoI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
