Good point.
I think the try catch should look like following:
try {
invokeNext();
} catch(CacheException ce) {
log.*trace*("Cache excption ", ce); //this is expected an logged as
such (trace)
..etc
} catch (Throwable th) {
log.error("unexpected error",th); //unexpected
...etc
}
Wdyt?
On Aug 13, 2009, at 6:00 PM, Manik Surtani wrote:
Guys,
I see this coming up when I run the test suite quite often, even on
tests that should not be exercising this code:
2009-08-13 15:53:29,188 ERROR [InvocationContextInterceptor]
(PerCacheExecutorThread-1) Execution error:
org.infinispan.util.concurrent.locks.DeadlockDetectedException:
Deadlock request was detected for locally originated tx
DummyTransaction{xid=DummyXid{id=70}, status=1}; it was marked for
rollback
at
org
.infinispan
.interceptors
.DeadlockDetectingInterceptor
.handleDataCommand(DeadlockDetectingInterceptor.java:80)
at
org
.infinispan
.interceptors
.DeadlockDetectingInterceptor
.visitPutKeyValueCommand(DeadlockDetectingInterceptor.java:98)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors
.base
.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:
118)
at
org
.infinispan
.interceptors
.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at
org
.infinispan
.commands
.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:
57)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors
.base
.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:
118)
at
org
.infinispan
.interceptors
.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:185)
at
org
.infinispan
.interceptors
.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:
127)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors
.base
.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:
118)
at
org
.infinispan
.interceptors
.InvocationContextInterceptor
.handleAll(InvocationContextInterceptor.java:48)
at
org
.infinispan
.interceptors
.InvocationContextInterceptor
.handleDefault(InvocationContextInterceptor.java:34)
at
org
.infinispan
.commands
.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:
57)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors
.base
.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:
118)
at org.infinispan.tx.AsyncDeadlockDetectionTest
$
RemoteReplicationInterceptor
.handleDefault(AsyncDeadlockDetectionTest.java:160)
at
org
.infinispan
.commands
.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:
57)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors.InterceptorChain.invoke(InterceptorChain.java:
237)
at org.infinispan.CacheDelegate.put(CacheDelegate.java:326)
at org.infinispan.CacheDelegate.put(CacheDelegate.java:544)
at org.infinispan.CacheDelegate.put(CacheDelegate.java:179)
at
org
.infinispan
.test.PerCacheExecutorThread.run(PerCacheExecutorThread.java:98)
[pool-1-thread-6] Test
simpleReplicationTest
(org.infinispan.replication.SyncCacheListenerTest) succeeded.
Is this a little too alarming? It seems to happen on any thread
interrupt (see DeadlockDetectingInterceptor [1], lines 67 - 92).
There are often legitimate reasons for a thread to be interrupted
(e.g., a server being shut down). So throwing this exception every
time can be pretty scary. Perhaps this should be on INFO or DEBUG
level?
Cheers
Manik
[1]
http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev