Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Alexey, I just remind you about issue. 2017-02-20 16:42 GMT+03:00 Александр Меньшиков : > Alexey, > > I'm ready to make some conclusions. You can see result immediately here: > PR: https://github.com/apache/ignite/pull/1537/files > CI Tests:

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Alexey, I'm ready to make some conclusions. You can see result immediately here: PR: https://github.com/apache/ignite/pull/1537/files CI Tests: http://ci.ignite.apache.org/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull/1537/head I fixed only

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Alexander, I do not see why you would need to overwrite the cause field. What I meant in the previous email is that instead of setting a retry ready future in the checked exception, you would set a correct affinity topology version here. Then, during a construction of CacheException (unchecked,

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Alexey, I ran into some difficulties. Look at the method: GridNearTxFinishFuture.CheckBackupMiniFuture#onDhtFinishResponse(GridDhtTxFinishResponse res) *Throwable err* = res.checkCommittedError(); if (*err* != null) { if (*err* instanceof

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Okay, it seems good. So you want to remove field *readyFut* from *ClusterTopologyCheckedException* and add *CacheTopologyCheckedException* like *ClusterTopologyCheckedException* but initialize *readyFut* in constructor, yes? 2017-01-30 16:54 GMT+03:00 Alexey Goncharuk

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

In the example above there is no point of setting the retry future in the exception because it will be serialized and sent to a remote node. I see the only possible way to ensure this: make this be verified at compile time. This looks like a big change, but the draft may look like so: 1)

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Alexey, For GridCacheIoManager#sendNoRetry it's not necessary because exception will be ignored (or will cast to String). Perhaps my message was unclear. I try to say that three methods can throw "ClusterTopologyCheckedException" without any problem. But you are right, in some methods I can't

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

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

IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

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

[jira] [Created] (IGNITE-1948) ClusterTopologyCheckedException can return null for retryReadyFuture()

Denis Magda created IGNITE-1948: --- Summary: ClusterTopologyCheckedException can return null for retryReadyFuture() Key: IGNITE-1948 URL: https://issues.apache.org/jira/browse/IGNITE-1948 Project: Ignite