Fixed at r1675020. 2015-04-20 16:18 GMT+09:00 Keiichi Fujino <kfuj...@apache.org>:
> 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 > -- Keiichi.Fujino
