Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <457F0C54.2020400@kippdata.de>
Date: Tue, 12 Dec 2006 21:08:52 +0100
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Thunderbird 1.5.0.8 (X11/20061110)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
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
References: <20061212034600.A94DE1A981A@eris.apache.org>
 <457E9F46.3030101@apache.org> <457EB299.5030109@kippdata.de>
 <457F038A.4080507@hanik.com>
In-Reply-To: <457F038A.4080507@hanik.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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