You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2006/12/12 04:46:00 UTC
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
Author: markt
Date: Mon Dec 11 19:45:59 2006
New Revision: 486005
URL: http://svn.apache.org/viewvc?view=rev&rev=486005
Log:
Fix bug 40551. When restoring a session from a PersistentManager to w new node update the session Id with the new jvmRoute. Based on a patch by Chris Chandler.
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Request.java
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
Modified: tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Request.java
URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Request.java?view=diff&rev=486005&r1=486004&r2=486005
==============================================================================
--- tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Request.java (original)
+++ tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Request.java Mon Dec 11 19:45:59 2006
@@ -2207,6 +2207,12 @@
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);
+ }
session.access();
return (session);
}
Modified: tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java
URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java?view=diff&rev=486005&r1=486004&r2=486005
==============================================================================
--- tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java (original)
+++ tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java Mon Dec 11 19:45:59 2006
@@ -772,6 +772,20 @@
}
} else {
session = store.load(id);
+
+ String jvmRoute = getJvmRoute();
+ if (jvmRoute != null && session != null) {
+ String requestJvmRoute = null;
+ int index = id.indexOf(".");
+ if (index > 0) {
+ requestJvmRoute = id.substring(index + 1, id.length());
+ }
+ if (requestJvmRoute != null &&
+ !requestJvmRoute.equals(jvmRoute)) {
+ id = id.substring(0, index) + "." + jvmRoute;
+ session.setId(id);
+ }
+ }
}
} catch (ClassNotFoundException e) {
log.error(sm.getString("persistentManager.deserializeError", id, e));
Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=486005&r1=486004&r2=486005
==============================================================================
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Mon Dec 11 19:45:59 2006
@@ -86,6 +86,11 @@
Ben Clifford. (markt)
</fix>
<fix>
+ <bug>40551</bug>: When restoring sessions from a PersistentManager to
+ a new node ensure that the session ID is updated to reflect the new
+ jvmRoute. Based on a patch by Chris Chandler. (markt)
+ </fix>
+ <fix>
<bug>40585</bug>: Fix parameterised constructor for o.a.juli.FileHandler
so parameters have an effect. (markt)
</fix>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
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
Posted by Peter Rossbach <pr...@objektpark.de>.
Hi,
I have implemented a JvmRouteBinderValve that detect a session failover.
This valve rewrite the interal session id and send the change to
other backup nodes.
<Cluster ....>
<Valve
className="org.apache.catalina.cluster.tcp.ReplicationValve"
filter=".*\.gif;.*
\.js;.*\.css;.*\.png;.*\.jpeg;.*\.jpg;.*\.htm;.*\.html;.*\.txt;"
primaryIndicator="true" />
<Valve
className="org.apache.catalina.cluster.session.JvmRouteBinderValve"
enabled="true" />
<ClusterListener
className="org.apache.catalina.cluster.session.ClusterSessionListener" /
>
<ClusterListener
className="org.apache.catalina.cluster.session.JvmRouteSessionIDBinderLi
stener" />
</Cluster>
Valve is registered as JMX-MBean and this feature can be disabled by
runtime.
regards
Peter
Am 12.12.2006 um 14:46 schrieb Rainer Jung:
> 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.
>
> 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
>
>
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
Posted by Mark Thomas <ma...@apache.org>.
Filip Hanik - Dev Lists wrote:
> 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
That sounds like the right way forward to me. I'll revert my commit
later today.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
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
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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
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
Posted by Remy Maucherat <re...@apache.org>.
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.
That seems reasonable to me.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
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
Posted by Rainer Jung <ra...@kippdata.de>.
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
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
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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
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
Posted by Rainer Jung <ra...@kippdata.de>.
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.
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
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
Posted by Remy Maucherat <re...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org