On Mon, 2009-08-31 at 13:36 +0200, Martin Grotzke wrote: > 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 Sorry, I forgot to remove these links here, I just pasted them into this mail for using the short versions below - sorry for confusion!
Cheers, Martin > > > 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
