This NPE has been caused by that apply the diff data to a ReplicatedMapEntry that has not set a MapOwner. Usually, ReplicatedMapEntry always has to have the MapOwner. I think this is probably a bug. Please open Bugzilla entry. I will scrutinize the code.
2015-04-20 15:04 GMT+09:00 Keiichi Fujino <kfuj...@apache.org>: > Hi > > Are there other error or exception in your log? > > Please show us your cluster configuration in your server.xml. > e.g. > - What is mapSendOptions? > - Which Interceptor do you use? > > > > 2015-04-15 3:55 GMT+09:00 Théo Chamley <theo...@mley.fr>: > >> Hello, >> >> I have a working Tomcat 8.0.15 cluster with 3 members with the >> BackupManager as session manager. >> The session replication is mostly working except in a few cases. In those >> cases, I get the following error: >> >> 09-Apr-2015 12:16:58.369 SEVERE [Tribes-Task-Receiver-6] >> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived >> Unable to apply diff to key:3B286B4C7CA060163A00988969D21923 >> java.lang.NullPointerException >> at >> org.apache.catalina.ha.session.DeltaSession.applyDiff(DeltaSession.java:164) >> at >> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.messageReceived(AbstractReplicatedMap.java:664) >> at >> org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:293) >> at >> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) >> at >> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:112) >> at >> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) >> at >> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) >> at >> org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.messageReceived(ThroughputInterceptor.java:89) >> at >> org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:81) >> at >> org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:260) >> at >> org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:240) >> at >> org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:206) >> at >> org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:97) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> >> >> I was able to replicate the problem with a scenario in the application, >> but I was not able to understand the underlying problem. >> This happens when the user is making a very specific request and this >> request arrives on a Tomcat where his session is not stored, forcing the >> Tomcat to fetch the session elsewhere. >> >> The 3 tomcats are on the same network with a very low network latency. >> >> Does anybody has some advice on how to debug this problem? >> >> For now, I got around it with sticky sessions on mod_jk, but I find this >> very unsatisfactory. >> >> Thank you in advance for your help, >> >> //Théo >> >> -- >> Keiichi.Fujino >> > -- Keiichi.Fujino
