Getting InterruptedException while putting into tree cache

[sg283]

I am using JBoss Cache 1.4.1 SP3. We are using PESSIMISTIC locking scheme with isolation level READ_UNCOMMITED.
While writing into the cache, sometimes we get InterruptedException. However, the API(put method in org.jboss.cache.TreeCache) only throws CacheException.

Here is the stacktrace:-

04 Aug 07 16:24:06, ERROR com.tg.logging.TGLogger: [pool-2-thread-177] error:166 com.tg.ws.WSException: WSException(String message, Throwable cause): java.lang.InterruptedException
com.tg.cache.manager.TGCacheException: java.lang.InterruptedException
at com.tg.ws.abacus.AbacusFareService.putResponseInCache(AbacusFareService.java:667)
at com.tg.ws.abacus.AbacusFareService_1_5.getFaresFromCacheOrWSForRequest(AbacusFareService_1_5.java:187)
at com.tg.ws.abacus.FarePoolHandler.execute(FarePoolHandler.java:29)
at com.tg.ws.abacus.FarePoolHandler.execute(FarePoolHandler.java:15)
at com.tg.parallel.concurrent.JavaConcurrentPoolExecutor$CallableAdapter.call(JavaConcurrentPoolExecutor.java:93)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: java.lang.InterruptedException
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5875)
at org.jboss.cache.TreeCache.put(TreeCache.java:3833)
at com.tg.cache.manager.FareCacheProviderImpl.addToCache(FareCacheProviderImpl.java:119)
at com.tg.ws.abacus.AbacusFareService.putResponseInCache(AbacusFareService.java:646)
... 9 more
Caused by: java.lang.InterruptedException
at EDU.oswego.cs.dl.util.concurrent.NullSync.attempt(NullSync.java:38) at org.jboss.cache.lock.IdentityLock.acquireReadLock(IdentityLock.java:252)
at org.jboss.cache.Node.acquireReadLock(Node.java:512)
at org.jboss.cache.Node.acquire(Node.java:474)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:379)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:307)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:175)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:186)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:212)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:365)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
... 12 more

[genman]

JBoss Cache uses the older Doug Lea concurrent library which throws InterruptedException from all lock methods if the thread was interrupted. The newer 1.5 concurrent methods mostly don't do this.

It's mostly done as a favor. If a thread is interrupted, typically the purpose of this interrupt is for timely shutdown of the thread.

Regarding the exception thrown, any method in Java can throw a RuntimeException, which is what is happening here.

[sg283]

Whenever the InterruptedException is thrown nothing is written in cache.
Please suggest if I should handle this exception in my code and retry to put in cache. Will this ensure write in cache if InterruptedException is not thrown again.

[manik]

Why are you using READ_UNCOMMITTED? Any specific reason tp use such a weak isolation level?

[sg283]

The reason behind using READ_UNCOMMITED is that our cache read/write hit is very high. We are more concerned to get something from cache even if that data is no longer valid in terms of use. The application must display data to the user.

[manik]

Do you see this problem with READ_COMMITTED as well, or only READ_UNCOMMITTED?

[sg283]

If we chose READ_COMMITED, the thread would wait for the transaction to be commited. As I mentioned, in our application number of read/write is very high.
We can read the uncommited value rather that waiting for the transaction to be commited.
If we are getting InterruptedException, what should be the approach to handle this. Should I catch this exception and try to put again after some time, say around 100 ms or so? Will this help?

We are using JBoss AS 4.0.3 SP1 and JBoss Cache 1.4.1 SP3. We are using JBossTransactionManager.

[manik]

Yes, a retry would be the best approach.