http://github.com/magro/memcached-session-manager/blob/de2f6d6749226c685eef38b985411c00b11fe452/src/main/java/de/javakaffee/web/msm/CommitInterceptingActionHook.java http://github.com/magro/memcached-session-manager/blob/de2f6d6749226c685eef38b985411c00b11fe452/src/main/java/de/javakaffee/web/msm/SessionTrackerValve.java
On Sun, 2009-08-30 at 17:34 -0700, Bill Barker wrote: > "Martin Grotzke" <martin.grot...@javakaffee.de> wrote in message > news:1251665502.4485.70.ca...@localhost.localdomain.tld... > > >On Sun, 2009-08-30 at 14:57 -0400, Christopher Schultz wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > > > > > >Martin, > > > > >> On 8/30/2009 1:50 PM, Martin Grotzke wrote: > > >> I found the ActionHook within the coyote response, so I'd try to wrap > > > >this and intercept the action with ActionCode.ACTION_COMMIT. > > > > > > > >Is this the correct approach for solving this problem? > > > > > >Sounds like it has a decent chance of working. Have you tried it? > >Not yet, but I'll start this evening hopefully. > > > > Yes, this should work. It is the contract for ACTION_COMMIT that it sends > the headers down the wire regardless of which Connector you are using. I implemented this and it's working - great! My wrapping hook defines just an abstract method "beforeCommit". This hook is set on the coyote response (if a session was requested, just as an optimization), and restores the original action hook at the end of "beforeCommit". The hook can be seen here: http://is.gd/2JcSh The usage of the hook from within the valve is here: http://is.gd/2JcVD > > >> > > >Doing this kind of thing is always a risky proposition, since there are > >> lots of cases to test. > >Hmm, which cases do you have in mind? > > > > The main one I'd worry about is that it isn't guaranteed that ACTION_COMMIT > won't be invoked more than once on a request (although it is rare), so you > need to be able to handle this case. The second time it is called, the > o.a.coyote.Response object will show itself as committed, so that is all you > need to check. I'd keep a reference to the Response in my ActionHookWrapper > to keep my sanity, but it should also be the 'param' value to the action > method (but I haven't check if this is true in all Connectors). Yes, that's exactly what I did, and I also checked for the "isCommitted" property and additionally restored the original hook after the intercepting hook was invoked. > > The other one would be that Tomcat reuses instances of it's low-level > internal objects. So the Valve that wraps the ActionHook needs to check > that it isn't re-wrapping an instance of your ActionHookWrapper. Uuh, good to know, this might lead to weird issues. I'll add a check for this. Thx && cheers, Martin > > >> > > >> Any other thoughts on this? > > > > >> Two related thoughts: > > > > > >1. Do you need all of the content to be generated before this header is > > > set? If so, you'll need another strategy for 100% response buffering > > > in order to meet your needs (say, calculating a cryptographic hash of > > > the response content to include in a header). > > > > > >2. If you don't need #1, then why do you want to delay the header > > > setting as long as possible? > >To answer this, I need some more words. Basically, I'd like to add the > >cookie only under certain conditions, but then after all session > >modifications are definitely done. So what am I trying to do in more > >detail? > > > >I'm creating the memcached-session-manager ([1]) as a session-failover > >solution when running on tomcat. The memcached-session-manager is > >basically storing a session additionally in a memcached node after the > >request was processed - as a backup of the session. Normally, the > >session is read from the jvm local session map. But if a request shall > >be served for an unknown session id, the session is looked up in the > >memcached and restored if found. Sessions are still kept locally to have > >only one roundtrip to memcached for each request. As there might be > >several memcached nodes used for session backup, the memcached node is > >encoded in the session id, so that the appropriate memcached node is > >selected for backup or restore. > >In the case of a memcached failover, the memcached-session-manager > >selects another memcached node for session backup, and changes the > >session id accordingly. To let the client know that the session id has > >changed, it must send a new JSESSIONID cookie with the new session id. > > > >So for this case, I want to defer the memcached-failure detection as > >long as possible, until the response is committed. If I have a memcached > >node in failure state, the response will also get a cookie with the new > >session id, and at the end of the request the session id will be > >migrated to the new memcached node. > > > >Cheers, > >Martin > > > > > >[1] http://code.google.com/p/memcached-session-manager/ > > > > > > > > > >> - -chris > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.9 (MingW32) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> > >> iEYEARECAAYFAkqay5wACgkQ9CaO5/Lv0PCUMQCgrJVkybrwNQY8CmWdDRnrvS2c > >> XK0AnijgEiYnHEQtkFeGMIKErHcBciAt > >> =HgEA > >> -----END PGP SIGNATURE----- > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >-- > >Martin Grotzke > >http://www.javakaffee.de/blog/ > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: This is a digitally signed message part
