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]