Possible concurrency problem: Replicated version id X matches in-memory version for session ...

The message basically is saying that a replicated session is overriding an existing session in that node. Quite often the version id is 1 but regardless of the version id, the problem is the same. Here's an scenario:

Let's say you have a first request (r1) that lands on node x (x) and a second request (r2) land on node y (y). If r2 gets to y before r1 gets replicated to y, a new session will be created on y, which will get replicated to x overriding what r1 had created on x. Node x will them prompt the message that you're seeing because the replicated session from r2 is overriding the session created by r1 in x. This will only happen if a new session was created in y. There's also the possibility (remote) that y will log this message, for example if r1 created a new session in x and replicated it to y after r2 created a new session in y. Very unlikely but could still happen. There's even also the possibility of both nodes reporting it.

Whether this messages are something you should be concerned by depends on whether r1 or r2 store anything meaningful in the session. Basically, whichever server logged lost their copy of the session. So:

1. If r1 and r2 both store something meaningful, for sure a problem. One or the other is lost.

1. If r1 doesn't store data, but r2 does, it's probably OK. Not OK if y logs the message. OK if x logs the message.

1. If r2 doesn't store data, but r1 does, probably a problem. Not OK if x logs the message. OK if y logs the message.

The best way to completely avoid these messages is to use sticky sessions with mod_jk. When other load balancers are used, even if sticky sessions is used, these messages can still appear. For example, in the case of F5 BIG-IP load balancer, it provides sticky sessions using hash session persistence. This method hashes the JSESSIONID cookie and uses the value to determine a server for load balancing. Since there is no JESSSIONID cookie on the first request, but there are for subsequent requests, it is possible that the first request is being served by one server and subsequent requests are being served by another. This does not happen with mod_jk because it requires each Tomcat worker to configured to set a jvmRoute per node in the cluster which must match the worker (node) name in the mod_jk side. When Tomcat replies to the first request, it adds the jvmRoute value to the session id so that mod_jk later can redirect to the same node where the request landed first.

If you see these messages when using a Netscaler load balancer, see the following wiki to get advice on how to configure Netscaler to use sticky sessions.

I get "org.jboss.ha.framework.server.ClusterFileTransfer$ClusterFileTransferException: Did not receive response from remote machine..."