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]



Reply via email to