"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. >> > >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). 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. >> > >> 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
