All of the other threads are waiting in our code for the other thread to complete.

If we set the timeout in our code (which wait for the thread above to complete) less than the timeout of the jboss cache the writer thread above will complete ONLY once our waiting threads have timed out.

If we set our internal timeout greater than the timeout of the jboss cache then the writer thread will throw timeout errors.

We can reproduce this any the time using just 2 threads.

We have tried different settings, but can't get this to work correctly.

The only thing that we've found that didn't lock the cache up like this is to use the DummyTransactionManager.

So is the jboss cache tying in to the current EJB transaction when a simple read is done?

However 1) that shouldn't be used in production 2) the cache doesn't replicate with that transaction manager.

Some other notes: 1) the cache doesn't auto-deploy as in 4.0.1, so we have to load it manually in the constructor giving it the filename. (a jboss rep at JavaOne '09 seemed puzzled by this) 2) the jmxStatistics node caused a null pointer when the the api is parsed 3) if we comment out the transaction element or use "" for the value of transactionManagerLookupClass it throws a "class not found 'null'" error.

at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xedd51380> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
at java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:254)
at org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:249)
at org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:234)
at org.jboss.cache.interceptors.EvictionInterceptor.registerEvictionEventToRegionManager(EvictionInterceptor.java:252)
at org.jboss.cache.interceptors.EvictionInterceptor.visitGetKeyValueCommand(EvictionInterceptor.java:215)
at org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:97)

1) Red Hat does offer paid support for JBoss Cache as a part of the JBoss EAP subscription.

2) Interesting that using the dummy TM solves the problem - it is still a real TM capable of holding real locks. It's just that other components in the app server won't be using it as well. Perhaps there is some contention there.

3) jmxStats: could you please create a JIRA for this, and preferably attach a simple unit test?

4) Eviction: the general solution here is to either reduce the wakeup interval (JBC 3 uses millis to measure this so you can go under 1s if needed) or increase the eviction queue size. This may well be why your readers are hanging.