tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
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 19:31:22 GMT
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 

does that make sense?
> 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:

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

View raw message