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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
