• Bug
  • Status: Closed
  • 3 Minor
  • Resolution: Fixed
  • ehcache-jgroupsreplication
  • Reporter: jchristi
  • September 23, 2009
  • 0
  • Watchers: 0
  • July 27, 2012
  • August 30, 2010

Attachments

Description

Using version 0.3 of JMS Replication, the remote peer which listens for cache updates produces the following stack trace when it receives a request to update a DECORATED cache:

14-Apr-2009 16:47:28 net.sf.ehcache.distribution.jms.JMSCachePeer onMessage WARNING: Unable to handle JMS Notification: null java.lang.NullPointerException at net.sf.ehcache.distribution.jms.JMSCachePeer.put(JMSCachePeer.java:210) at net.sf.ehcache.distribution.jms.JMSCachePeer.handleNotification(JMSCachePeer.java:132) at net.sf.ehcache.distribution.jms.JMSCachePeer.handleObjectMessage(JMSCachePeer.java:305) at net.sf.ehcache.distribution.jms.JMSCachePeer.onMessage(JMSCachePeer.java:246) at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:967) at org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:122) at org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:192) at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122) at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43) 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)

The cause is that JMSCachePeer is used to obtain strictly Cache implementations and not the more general Ehcache implementations from the CacheManager; i.e. it should use cacheManager.getEhcache(cacheName) rather than cacheManager.getCache(cacheName).

I will submit a patch for this to be used against JMSCachePeer SVN Rev 855.

(If others use this to create their own version of JMS Replication then you should know that JMS Replication project won’t compile against the HEAD version of Ehcache since there are some changes due to JSR exceptions - perhaps this relates to Bug 2780720?? - anyhow my second patch file provides a patch to JMSCacheLoader and JMSCacheLoaderFactory)

I have a fix for this which Sourceforge Ticket ID: 2785071 - Opened By: alphabravo - 1 May 2009 14:24 UTC

Comments

Jon Christiansen 2009-09-23

Apologies if cloning wasn’t the best operation on this issue, but there is a nearly identical issue with JGroups replication, where replication does not function if your cache is a decorated cache.

Line 88 of method handleJGroupNotification in net.sf.ehcache.distribution.jgroups.JGroupManager does a CacheManager.getCache(), which will return null unless the object is strictly a Cache, therefore for DECORATED cache’s ends up being a no-op rather than the NPE that occurred in the JMS implementation.

As a side note, the javadoc in Cache states that SelfPopulatingCache, BlockingCache are decorators for Cache, but if you look at these Classes, they clearly state in their javadoc that they are decorators for Ehcache. Perhaps the javadoc can be made more consistent as well.

Jon Christiansen 2009-09-23

Patch to src/main/java/net/sf/ehcache/distribution/jgroups/JGroupManager.java which allowed my specific case to work.

Steve Harris 2009-09-23

Hey greg, how do you want to target these (release wise) since we don’t have names for releases for the sub projects like jgroups. If you want you can through a “due date” in to signal to your user when you think you’ll get to it?

BTW this comment is only viewable internally. That property is set in the “Viewable By:” thing below.

gluck 2010-08-30

Fixed. Now uses Ehcache rather than Cache, so decorated caches can now be replicated.