Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAN+WSNwoP4LjZFf2PniMviano-1zE3yLUtOsgAW4bixRC3rXGw@mail.gmail.com>
References: <CAN+WSNwoP4LjZFf2PniMviano-1zE3yLUtOsgAW4bixRC3rXGw@mail.gmail.com>
From: Alexey Goncharuk <alexey.goncharuk@gmail.com>
Date: Mon, 30 Jan 2017 12:24:13 +0300
Message-ID: <CABDss3g--bn76=xf-zwJLeVjjkWxs0yjqkDQ268kjR5wGTtgMQ@mail.gmail.com>
Subject: Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c19122602c22905474c610a
archived-at: Mon, 30 Jan 2017 09:24:20 -0000

--94eb2c19122602c22905474c610a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Alexander,

Do you have a use-case in mind which results in IgniteTopologyException
thrown from public API with retryFuture unset?

retryFuture makes sense only for certain cache operations and may be set
only in certain places in the code where we already know what to wait for.
I do not see how you can initialize this future, for example, in
 GridCacheIoManager#sendNoRetry(ClusterNode node, GridCacheMessage msg, byt=
e
plc)

--AG

2017-01-27 15:45 GMT+03:00 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=
=D1=80 =D0=9C=D0=B5=D0=BD=D1=8C=D1=88=D0=B8=D0=BA=D0=BE=D0=B2 <sharplermc@g=
mail.com>:

> 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 some case "retryReadyFuture" can left unset. But there a=
re
> 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 simpl=
e
> 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 only 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?
>

--94eb2c19122602c22905474c610a--