Val, it seems you spotted and issue. Please file a ticket - I would suggest to remove the exceptions entirely as in my understanding timeout logic for atomic operation will bring additional overhead, but most of the time atomic operations are instant. From timeout perspective, what differs atomic operation from a transaction is that you cannot predict when user releases lock he acquired inside a transaction, but atomic operation should have predictable timeout.
As far as your example. Currently, this will lead to java-level deadlock on synchronized sections for the cache entries (but when we move to pure thread-per-partition for atomic caches this will not be an issue any more https://issues.apache.org/jira/browse/IGNITE-4506). I would suggest we file a ticket to implement detection of java-level deadlock and allow user to configure policy to take appropriate action on deadlock wherever it happens - https://issues.apache.org/jira/browse/IGNITE-5811 Any other hang of the atomic operation seem to be caused by issues in Ignite's internal machinery - either hanged exchange or problems in message processing on some node (e.g. all threads are busy and/or in deadlock) which again should result in notifying user and stopping node (by default). --Yakov
