• Bug
  • Status: Closed
  • Resolution: Fixed
  • drb
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • September 22, 2009
  • September 22, 2009

Description

I am getting the below stack trace when using async replication with two cache on my local Windows XP machine. I tried running with prefer IPv4 (which does not make a difference). The Element that will be replicated is surely not null since I am doing test that generate a numbered sequence of entries into the local cache and them I am watching the distribution behaviour. I am using Spring with custom factory bean to inject the replication behaviour into the caches.

WARN 2008-06-25 10:52:55,893 [Replication Thread] distribution.RMIAsynchronousCacheReplicator#flushReplicationQueue: Unable to send message to remote peer. Message was: Element cannot be null java.lang.IllegalArgumentException: Element cannot be null at net.sf.ehcache.Cache.put(Cache.java:669) at net.sf.ehcache.distribution.RMICachePeer.put(RMICachePeer.java:174) at net.sf.ehcache.distribution.RMICachePeer.send(RMICachePeer.java:217) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142) at net.sf.ehcache.distribution.RMICachePeer_Stub.send(Unknown Source) at net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator.flushReplicationQueue(RMIAsynchronousCacheReplicator.java:309) at net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator.replicationThreadMain(RMIAsynchronousCacheReplicator.java:122) at net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator.access$100(RMIAsynchronousCacheReplicator.java:55) at net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator$ReplicationThread.run(RMIAsynchronousCacheReplicator.java:368) Sourceforge Ticket ID: 2002319 - Opened By: nobody - 25 Jun 2008 09:04 UTC

Comments

Sourceforge Tracker 2009-09-21

Logged In: YES user_id=693320 Originator: NO

Hi

This problem is caused because Element in the async replication queue are soft referenced. What has happened in your case is that the soft reference has been collected. SoftReferences sound great but I have found from JVM testing on the Sun JDK that they are reclaimed in preference to increasing heap memory. I have changed put to log a warning message with the fix:

public final void put(Element element, boolean doNotNotifyCacheReplicators) throws IllegalArgumentException, IllegalStateException, CacheException { checkStatus();

    if (disabled) {
        return;
    }

    if (element == null) {
        if (doNotNotifyCacheReplicators == true) {
            //this can happen because of soft references
            LOG.warn("Element from replicated put is null. This happens because the element is a SoftReference and it has been collected." +
                    "Increase heap memory on the JVM or set -Xms to be the same as -Xmx to avoid this problem.");
        } else {
            throw new IllegalArgumentException("Element cannot be null");
        }
    }

Thanks for your bug. This is in trunk and will be in 1.5.0 which is out this weekend.

Greg Comment by: gregluck - 9 Jul 2008 07:53 UTC

Fiona OShea 2009-09-22

Re-opening so that I can properly close out these issues and have correct Resolution status in Jira