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.
> > 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? > > > 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/
signature.asc
Description: This is a digitally signed message part
