[
https://issues.apache.org/jira/browse/IGNITE-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15842754#comment-15842754
]
Alexander Menshikov commented on IGNITE-1948:
---------------------------------------------
I found a lot of using "ClusterTopologyCheckedException" exception. In most
use-case these exceptions were just ignored. It's easier to see if issue-4612
will be applied (I'm waiting for code review by my team leader) where I renamed
all unused exceptions in the "ignored".
It means that in most case "retryReadyFuture" can left unset. But there are
code where exception is being getting from "get()" method in some "future"
class and don't ignored (exception is sending to method
"GridFutureAdapter#onDone()" for example).
So I decided not to do a deep global analysis of code and make some simple
rules.
1. If some method "X" throws ClusterTopologyCheckedException and ignores it (or
converts to String, there are some variants to lose exception like object) in
all methods that call the method "X", then we can don't set "retryReadyFuture"
for optimization. But this should be clarified in javadoc.
2. But if exception escapes at least once like object: we must set
"retryReadyFuture" in that method.
A few times when call tree was simple, I went deeper.
So I found three methods which can throw "ClusterTopologyCheckedException"
without setting "retryReadyFuture":
1. IgfsFragmentizerManager#sendWithRetries(UUID nodeId,
IgfsCommunicationMessage msg)
2. GridCacheIoManager#sendNoRetry(ClusterNode node, GridCacheMessage msg, byte
plc)
3. GridCacheIoManager#sendOrderedMessage(ClusterNode node, Object topic,
GridCacheMessage msg, byte plc, long timeout)
In all other methods "ClusterTopologyCheckedException" escapes away too far.
What do you think about this approach to make compromise between optimization
and correctness?
> ClusterTopologyCheckedException can return null for retryReadyFuture()
> ----------------------------------------------------------------------
>
> Key: IGNITE-1948
> URL: https://issues.apache.org/jira/browse/IGNITE-1948
> Project: Ignite
> Issue Type: Bug
> Components: general
> Reporter: Denis Magda
> Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> It was noted that {{ClusterTopologyCheckedException}} ready future can be
> null.
> Go though all the places where this kind of exception is being initialized
> and check why the ready future is not set in some cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
