tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: svn commit: r486005 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/Request.java catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java 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:
>>> markt@apache.org 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message