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
If I understand the discussion correctly it is being suggested that we attempt using the JvmRouteBinderValve for the same functionality provided in the originally submitted patch. I believe the problem we ran into was the JvmRouteBinderValve assumes that we are using the SimpleTcpCluster implementation, when we're actually using the JDBC persistence manager for replication. It's entirely possible I am missing something, but it doesn't appear the JvmRouteBinderValve solves this particular problem. Chris Original Message 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 From: Mark Thomas [EMAIL PROTECTED] Date: Wed, December 13, 2006 5:55 am To: Tomcat Developers List dev@tomcat.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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
if that is the case, the fix still belongs in the JvmRouteBinderValve, feel free to submit a patch in that one so that it works even if the cluster is not present Filip [EMAIL PROTECTED] wrote: If I understand the discussion correctly it is being suggested that we attempt using the JvmRouteBinderValve for the same functionality provided in the originally submitted patch. I believe the problem we ran into was the JvmRouteBinderValve assumes that we are using the SimpleTcpCluster implementation, when we're actually using the JDBC persistence manager for replication. It's entirely possible I am missing something, but it doesn't appear the JvmRouteBinderValve solves this particular problem. Chris Original Message 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 From: Mark Thomas [EMAIL PROTECTED] Date: Wed, December 13, 2006 5:55 am To: Tomcat Developers List dev@tomcat.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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
I am planning for TC6.0 to propose to make the JVMRouteId be something at the edge, it should never make it as far as into the session manager. when Manager.getSession is called, the jvmRoute should already be stripped out it, and before the cookie is sent, it should be appended. It would have been much cleaner if the manager never had known about the jvmRoute to begin with. Filip Filip Hanik - Dev Lists wrote: if that is the case, the fix still belongs in the JvmRouteBinderValve, feel free to submit a patch in that one so that it works even if the cluster is not present Filip [EMAIL PROTECTED] wrote: If I understand the discussion correctly it is being suggested that we attempt using the JvmRouteBinderValve for the same functionality provided in the originally submitted patch. I believe the problem we ran into was the JvmRouteBinderValve assumes that we are using the SimpleTcpCluster implementation, when we're actually using the JDBC persistence manager for replication. It's entirely possible I am missing something, but it doesn't appear the JvmRouteBinderValve solves this particular problem. Chris Original Message 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 From: Mark Thomas [EMAIL PROTECTED] Date: Wed, December 13, 2006 5:55 am To: Tomcat Developers List dev@tomcat.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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Remy Maucherat wrote:
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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/
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:
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
Rainer Jung wrote:
Remy Maucherat wrote:
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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:
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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:
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
Author: markt
Date: Mon Dec 11 19:45:59 2006
New Revision: 486005
URL: http://svn.apache.org/viewvc?view=revrev=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=diffrev=486005r1=486004r2=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=diffrev=486005r1=486004r2=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=diffrev=486005r1=486004r2=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
+bug40551/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
bug40585/bug: Fix parameterised constructor for
o.a.juli.FileHandler
so parameters have an effect. (markt)
/fix
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
