Some work in progress. I added some logging to JvmRouteValve, ClusteredValve and SharedLocalYieldingClusterLockManagerSupport in order to seee which session related requests are coming into each node and (ii) what is happening when the global lock is being acquired (which triggers the exception).
I did a run of the session replication test, processed the logs and ended up with four logs which track the activity of a single session which triggers the exception.
I have attached the logs as view-perf18, view-perf19, view-perf20 and view-perf21.
I have also created a small graphic showing the relationships between hosts, views received, failures and which hosts are receiving requests involving that session. The graphic is called sessionTravel.gif. What is clear is that in view 10, both perf18 and pef19 are trying to acquire the session ownership.
There are some issues with the JVMRoute processing which i'm still looking into. What is odd is that two requests involving the same session are being processed by different hosts.