You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Valentin Kulichenko (JIRA)" <ji...@apache.org> on 2015/08/11 08:25:45 UTC
[jira] [Commented] (IGNITE-1151) Cache operations can throw
ClusterTopologyException without wrapping it into CacheException
[ https://issues.apache.org/jira/browse/IGNITE-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681308#comment-14681308 ]
Valentin Kulichenko commented on IGNITE-1151:
---------------------------------------------
I analyzed this use case once more and it looks like the behaviour is correct. Transactions API (e.g., commit or rollback operations) does not belong to cache package and therefore throws {{IgniteException}} (or its descendants like {{ClusterTopologyException}}). Cache operations (put, remove, etc.), on the other hand, always throw {{CacheException}}.
I will properly document this and will close this ticket.
> Cache operations can throw ClusterTopologyException without wrapping it into CacheException
> -------------------------------------------------------------------------------------------
>
> Key: IGNITE-1151
> URL: https://issues.apache.org/jira/browse/IGNITE-1151
> Project: Ignite
> Issue Type: Bug
> Components: cache
> Affects Versions: 1.1.4
> Reporter: Valentin Kulichenko
> Assignee: Valentin Kulichenko
> Labels: Usability
> Fix For: ignite-1.4
>
>
> This was reported by one of our users who was testing cache transactions and other operation with changing topology. He claims that he had to catch {{ClusterTopologyException}} directly in some cases, so he had to write the code like this:
> {code}
> try (final Transaction tx = txn.txStart()) {
> ...
> }
> catch (final CacheException e) {
> if (!(e.getCause() instanceof ClusterTopologyException)) {
> throw e;
> }
> // retry
> failure = e;
> }
> catch (final ClusterTopologyException e) {
> // retry
> failure = e;
> }
> {code}
> Cache operations should throw only {{CacheException}}. Need to revisit exception handling logic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)