tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: svn commit: r486005 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/ catalina/src/share/org/apache/catalina/session/ webapps/docs/changelog.xml
Date Tue, 12 Dec 2006 20:08:52 GMT
My impression now is, that we should backout the commit and the user 
should instead first try to use the existing Valve as described by Peter.

Filip Hanik - Dev Lists wrote:
> Rainer Jung wrote:
>> Remy Maucherat wrote:
>>> wrote:
>>>>              if ((session != null) && !session.isValid())
>>>>                  session = null;
>>>>              if (session != null) {
>>>> +                if(!requestedSessionId.equals(session.getId())) {
>>>> +                    Cookie cookie = new 
>>>> Cookie(Globals.SESSION_COOKIE_NAME,
>>>> +                            session.getIdInternal());
>>>> +                    configureSessionCookie(cookie);
>>>> +                    response.addCookie(cookie);
>>>> +                }
>>> I don't know if that's a good idea. It looks a bit risky. I think it 
>>> should include && (getContext() != null) && getContext().getCookies().
>>> Rémy
>> Also if I remember correctly, session replication with delta manager 
>> (default) applies replica messages to sessions with the same id: So in 
>> a three node cluster with one node failing renaming the id on a second 
>> node might break replication from the second to the third. 
>> Unfortunately I can't check right now, but since it might be, that 
>> 5.5.21 is not too far, I would find this new rewriting behaviour a bit 
>> risky as a default.
> Peter did the session rewriting implementation, I haven't worked on it, 
> but it seems that the session Id to piggy back on could have been done 
> without going that deep in the code.
> Not sure what the concern is in Rainer's statement above, but that 
> scenario should work just fine as the cluster replicates the sessionId 
> changes, again a far from ideal solution.
> It would have been easier to filter out the JVM route way before we hit 
> the session manager, and then append it before the request gets sent 
> out, that way we could avoid both the patch above and the session Id 
> listeners and jvm route binder stuff. so in short terms, the session 
> manager never knows about jvmRoute, that is something happening on the 
> "edge".
> does that make sense?
> Filip
>> I'm also asking Peter about the state of his rewriting listeners, 
>> because I somehow remember a functionality like that might already exist.
>> Maybe Filip likes to comment on my first concern.
>> Regards,
>> Rainer

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

View raw message