tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: How to set header (directly) before response is committed
Date Mon, 31 Aug 2009 14:33:16 GMT
Hash: SHA1


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
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message