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