Ilya Kasnacheev created IGNITE-7719:
---------------------------------------
Summary: Avoid wrapping InterruptedException in CacheException or
IgniteException
Key: IGNITE-7719
URL: https://issues.apache.org/jira/browse/IGNITE-7719
Project: Ignite
Issue Type: Task
Affects Versions: 2.5
Reporter: Ilya Kasnacheev
It is a pity to see stack traces like this:
{code:java}
javax.cache.CacheException: Failed to run reduce query locally.
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:839)
~[ignite-indexing-2.1.10.jar:2.1.10]
...
Caused by: org.apache.ignite.internal.IgniteInterruptedCheckedException
at org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7463)
~[ignite-core-2.1.10.jar:2.1.10]
... 7 more
Caused by: java.lang.InterruptedException
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
~[?:1.8.0_92]
... 7 more{code}
Here we leave almost zero chance to end-user of the code to properly handle
InterruptedException, short of digging into CacheException's causes.
When people use this code in while (true) try{}catch(){log} loop they will get
horrible problems here when interruption happens, as in clobbering their whole
log with exceptions. This isn't acceptable.
What should be done:
- Make sure we never wrap random IgniteCheckedException into IgniteException or
CacheException (because it might be IgniteInterruptedCheckedException). Use
some method that does proper checking on exception type, throwing something
appropriate.
IMO it's much better to throw unexpected IgniteInterruptedException than a
generic one.
- If needed, declare on all affected methods that they may throw
IgniteInterruptedException.
- Have a check in CacheException's constructor to re-throw
IgniteInterruptedException if it is passed as an argument. Ditto for
IgniteException. They should never be wrapped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
