tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
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 Wed, 13 Dec 2006 00:47:45 GMT
Rainer Jung wrote:
> 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.
I agree,
Filip
>
> 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
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message