On Mon, 2009-08-31 at 10:33 -0400, Christopher Schultz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin, > > On 8/30/2009 4:51 PM, Martin Grotzke wrote: > > On Sun, 2009-08-30 at 14:57 -0400, Christopher Schultz wrote: > > > >> 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? > > Well, you have to test it when you have a tiny response (including > things like redirects, 304s, etc.), when you have a huge response (large > static file, perhaps), when you have a large response AND a redirect > (which might actually fail on its own), etc. Yes, these are good things to check, I'll write tests for such cases.
> > >> 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. > > I would recommend that you re-think your architecture if this is a > concern. It's best to do all your state-changes on the server /before/ > any response is generated. If you stick to this rule, then you can set > your cookie before the 1st byte of the response is even emitted, and it > will significantly uncomplicate your life. As I'm creating a library that shall be usable in different projects, it's not on me to decide when the session is accessed and when the response is created. However, if there will be issues with the current approach (intercepting the response.commit) I'll have to reconsider a different way. > > > 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. > > Shouldn't you know when you first try to access the session that a > memcached-failure condition has been detected? Nope, the memcached might fail directly in the *moment* after the session was created but before the session is going to be stored for backup - of course this is not very probable, but possible. And for long running requests the probability increases. > If so, you don't have to > wait until the end of the response to put that into a header (and why do > you even need it in the header)? Just copying what I already wrote: > > 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. Cheers, Martin > > This doesn't sound like you need any delayed processing whatsoever. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqb3ywACgkQ9CaO5/Lv0PB5SACgv1z/VjTRA1l++og0GNmMfR4B > ILgAnROBRRgRuP1SRuV+EEXEC4je9WGm > =zBml > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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
