Possible concurrency problem: Replicated version id X matches in-memory version for session ...
2013-07-17 14:49
309 查看
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:
If r1 and r2 both store something meaningful, for sure a problem. One or the other is lost.
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.
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..."
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:
If r1 and r2 both store something meaningful, for sure a problem. One or the other is lost.
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.
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..."
相关文章推荐
- Possible concurrency problem: Replicated version id X matches in-memory version for session ...
- How to Enable SQL_TRACE for Another Session or in MTS Using Oradebug(文档 ID 1058210.6)
- shining cento in book reading: handle out of memory problem for new operator -by register a global SetNewHandler
- Struts Problem Report :Could not obtain transaction-synchronized Session for current thread
- Performance verifying for Sqlite in-memory mode.
- XFS: possible memory allocation deadlock in kmem_alloc (mode:0x2d0)
- 【ask】Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.
- tokbox获取sessionId和tokenId for c++版本
- Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug
- exercise for memory-allocation functions in c run-time library
- Method and apparatus for providing total and partial store ordering for a memory in multi-processor system
- Fix the problem: java.lang.OutOfMemoryError: PermGen space in Java development
- Request header field sessionId is not allowed by Access-Control-Allow-Headers in preflight response.
- org.hibernate.AssertionFailure: null id in xxx entry (don't flush the Session after an except)解决方法
- How To Enable/Disable Archive Logging In RAC Environment for 10.2 and higher version
- Web 2.0 portal development support for features in IBM WebSphere Portal Version 6.1
- Solve: Your project references the latest version of Entity Framework (for MySQL) in Visual Studio 2013
- MEMORY OPTIMIZATION FOR IOS APPS DEVELOPED IN UNITY
- tomcat 启动慢 Creation of SecureRandom instance for session ID generation using [SHA1PRNG]
- You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use