You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael <ml...@gmx.net> on 2006/03/15 16:57:43 UTC
Problems with the ReplicationValve
Hi all,
we tried to switch with a clusterable webapp from Tomcat 5.0
to Tomcat 5.5 and ran into problems with the primary session
indication by the ReplicationValve. We have a cluster with two
nodes (let's call them 'A' and 'B'). A sticky session is created
at node A and is reported there as primary session. When we shut
down node A the next request will be routed to the secondary
node B and the primary indicator attribute in the request will
be set to "false". Everything's fine up to here.
After a request is served by a secondary node, this node should
become primary, so further requests to node B should be indicated
as primary session again. With tomcat 5.5 (tested with 5.5.15
and 5.5.16-beta) and a cluster with two nodes this doesn't
work any longer.
Looks like the problem starts here (see ReplicationValve.java 360ff):
360 if(containerCluster.hasMembers()) {
361 sendReplicationMessage(request, totalstart, isCrossContext, clusterManager, containerCluster);
362 } else {
362 resetReplicationRequest(request,isCrossContext);
363 }
When node A is gone, the cluster doesn't have other members any
more, so no replication messages are created and there is no
call to the DeltaManager "DeltaManager.requestCompleted(..)"
which set's the primary session flag to 'true' again.
Can anyone confirm this problem?
Unfortunately the numbers of the placeholders from
"ReplicationValve.session.indicator" in
org.apache.catalina.cluster.tcp.LocalStrings.properties are
wrong, so you have to fix them first if you want to see the
value of the primary session indicator in the debug log (see
diff below).
Regards,
Michael
-=-=-=-=-=-=-=-
diff -ru apache-tomcat-5.5.16-src/container/modules/cluster/src/share/org/apache/catalina/cluster/tcp/LocalStrings.properties tomcat-5.5/container/modules/cluster/src/share/org/apache/catalina/cluster/tcp/LocalStrings.properties
--- apache-tomcat-5.5.16-src/container/modules/cluster/src/share/org/apache/catalina/cluster/tcp/LocalStrings.properties 2006-03-05 02:25:35.000000000 +0100
+++ tomcat-5.5/container/modules/cluster/src/share/org/apache/catalina/cluster/tcp/LocalStrings.properties 2006-03-14 17:16:15.867578000 +0100
@@ -48,7 +48,7 @@
ReplicationValve.send.failure=Unable to perform replication request.
ReplicationValve.send.invalid.failure=Unable to send session [id={0}] invalid message over cluster.
ReplicationValve.session.found=Context {0}: Found session {1} but it isn't a ClusterSession.
-ReplicationValve.session.indicator=Context {0}: Primarity of session {0} in request attribute {1} is {2}.
+ReplicationValve.session.indicator=Context {0}: Primarity of session {1} in request attribute {2} is {3}.
ReplicationValve.session.invalid=Context {0}: Requested session {1} is invalid, removed or not replicated at this node.
ReplicationValve.stats=Average request time= {0} ms for Cluster overhead time={1} ms for {2} requests {3} filter requests {4} send requests {5} cross context requests (Request={6} ms Cluster={7} ms).
SimpleTcpCluster.event.log=Cluster receive listener event {0} with data {1}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problems with the ReplicationValve
Posted by Peter Rossbach <pr...@objektpark.de>.
OK,
I have also test it, and commit....
Many thanks for reporting the bug.
Peter
Am 15.03.2006 um 19:13 schrieb Michael:
> Hi Peter!
>
> Peter Rossbach wrote:
>> yes that is true here my fix:
> [...]
>> Can you please test this, then I can commit the change.
>
> Yes, it works! Many thanks! :)
>
>> Tipp:
>> That your client/browser also know that B is forever the primary
>> use JvmRouteBinderValve. That helps very much for longer shutdowns
>> and more then two node clusters. Configure it after ReplicationValve.
>
> The JvmRouteBinderValve is a very interesting enhancement, but
> we must not change our session-id in that project. However, I'll
> think about it for another application... ;)
>
> Thanks again,
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problems with the ReplicationValve
Posted by Michael <ml...@gmx.net>.
Hi Peter!
Peter Rossbach wrote:
>
> yes that is true here my fix:
[...]
> Can you please test this, then I can commit the change.
Yes, it works! Many thanks! :)
> Tipp:
> That your client/browser also know that B is forever the primary use
> JvmRouteBinderValve. That helps very much for longer shutdowns
> and more then two node clusters. Configure it after ReplicationValve.
The JvmRouteBinderValve is a very interesting enhancement, but
we must not change our session-id in that project. However, I'll
think about it for another application... ;)
Thanks again,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problems with the ReplicationValve
Posted by Peter Rossbach <pr...@objektpark.de>.
Hey Michael,
yes that is true here my fix:
ReplicationValve:
protected void resetReplicationRequest(Request request, boolean
isCrossContext) {
Session contextSession = request.getSessionInternal(false);
if(contextSession != null & contextSession instanceof
DeltaSession){
resetDeltaRequest(contextSession);
((DeltaSession)contextSession).setPrimarySession(true);
}
if(isCrossContext) {
Object sessions = crossContextSessions.get();
if(sessions != null && sessions instanceof List
&& ((List)sessions).size() >0) {
Iterator iter = ((List)sessions).iterator();
for(; iter.hasNext() ;) {
Session session = (Session)iter.next();
resetDeltaRequest(session);
if(session instanceof DeltaSession)
((DeltaSession)
contextSession).setPrimarySession(true);
}
}
}
}
Can you please test this, then I can commit the change.
Tipp:
That your client/browser also know that B is forever the primary use
JvmRouteBinderValve. That helps very much for longer shutdowns
and more then two node clusters. Configure it after ReplicationValve.
regards
Peter
Am 15.03.2006 um 16:57 schrieb Michael:
> Hi all,
>
> we tried to switch with a clusterable webapp from Tomcat 5.0
> to Tomcat 5.5 and ran into problems with the primary session
> indication by the ReplicationValve. We have a cluster with two
> nodes (let's call them 'A' and 'B'). A sticky session is created
> at node A and is reported there as primary session. When we shut
> down node A the next request will be routed to the secondary
> node B and the primary indicator attribute in the request will
> be set to "false". Everything's fine up to here.
>
> After a request is served by a secondary node, this node should
> become primary, so further requests to node B should be indicated
> as primary session again. With tomcat 5.5 (tested with 5.5.15
> and 5.5.16-beta) and a cluster with two nodes this doesn't
> work any longer.
>
> Looks like the problem starts here (see ReplicationValve.java 360ff):
>
> 360 if(containerCluster.hasMembers()) {
> 361 sendReplicationMessage(request, totalstart,
> isCrossContext, clusterManager, containerCluster);
> 362 } else {
> 362 resetReplicationRequest(request,isCrossContext);
> 363 }
>
> When node A is gone, the cluster doesn't have other members any
> more, so no replication messages are created and there is no
> call to the DeltaManager "DeltaManager.requestCompleted(..)"
> which set's the primary session flag to 'true' again.
>
> Can anyone confirm this problem?
>
> Unfortunately the numbers of the placeholders from
> "ReplicationValve.session.indicator" in
> org.apache.catalina.cluster.tcp.LocalStrings.properties are
> wrong, so you have to fix them first if you want to see the
> value of the primary session indicator in the debug log (see
> diff below).
>
> Regards,
> Michael
>
> -=-=-=-=-=-=-=-
> diff -ru apache-tomcat-5.5.16-src/container/modules/cluster/src/
> share/org/apache/catalina/cluster/tcp/LocalStrings.properties
> tomcat-5.5/container/modules/cluster/src/share/org/apache/catalina/
> cluster/tcp/LocalStrings.properties
> --- apache-tomcat-5.5.16-src/container/modules/cluster/src/share/
> org/apache/catalina/cluster/tcp/LocalStrings.properties 2006-03-05
> 02:25:35.000000000 +0100
> +++ tomcat-5.5/container/modules/cluster/src/share/org/apache/
> catalina/cluster/tcp/LocalStrings.properties 2006-03-14
> 17:16:15.867578000 +0100
> @@ -48,7 +48,7 @@
> ReplicationValve.send.failure=Unable to perform replication request.
> ReplicationValve.send.invalid.failure=Unable to send session [id=
> {0}] invalid message over cluster.
> ReplicationValve.session.found=Context {0}: Found session {1} but
> it isn't a ClusterSession.
> -ReplicationValve.session.indicator=Context {0}: Primarity of
> session {0} in request attribute {1} is {2}.
> +ReplicationValve.session.indicator=Context {0}: Primarity of
> session {1} in request attribute {2} is {3}.
> ReplicationValve.session.invalid=Context {0}: Requested session
> {1} is invalid, removed or not replicated at this node.
> ReplicationValve.stats=Average request time= {0} ms for Cluster
> overhead time={1} ms for {2} requests {3} filter requests {4} send
> requests {5} cross context requests (Request={6} ms Cluster={7} ms).
> SimpleTcpCluster.event.log=Cluster receive listener event {0} with
> data {1}
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org