Pavel,
The exception from an AtomicSequence looks like a bug to me. Ignite should
retry all operations that do not involve user's logic, this stands for
AtomicSequence. I believe such handling already present in AtomicLong, so
it should not be difficult to fix.
The only case when a user must handle TopologyException is an explicit
transaction. In this case, the transaction involves particular user logic
that cannot be captured and retried by Ignite, so the exception handling
should be covered by the user.
The way you handled the topology exception looks correct to me.
--AG
2018-03-14 20:47 GMT+03:00 Dmitry Pavlov <dpavlov....@gmail.com>:
> Hi Nikolay,
>
> How do you think which was idea / the best practice to handling exceptions
> here?
>
> Why exception here may have difference?
>
> Sincerely,
> Dmitriy Pavlov
>
> ---------- Forwarded message ---------
> From: Vinokurov Pavel <vinokurov.pa...@gmail.com>
> Date: вт, 13 мар. 2018 г. в 5:52
> Subject: Atomic sequence and topology exception
> To: <dev@ignite.apache.org>
>
>
> Igniters!
>
> I have a few questions related to a replicated atomic sequence and an
> topology exception.
> In my case after one server node has left cluster, on a client node the
> execution of the *IgniteAtomicSequence#incrementAndGet()* throws
> exception:
>
> org.apache.ignite.cluster.ClusterTopologyException: Failed to acquire lock
> for keys (primary node left grid, retry transaction if possible)
> [keys=[UserKeyCacheObjectImpl [part=94, val=GridCacheInternalKeyImpl
> [name=seq, grpName=default-ds-group], hasValBytes=true]],
> node=a047ec4b-7de6-4503-9691-a5d7e03e267f]
>
> I handle exception in that way:
>
> IgniteAtomicSequence seq = ignite.atomicSequence(Const.SEQ, new
> AtomicConfiguration().setAtomicSequenceReserveSize(0)
> .setCacheMode(CacheMode.REPLICATED),0, Boolean.TRUE);
> while(true){
> //do some logic
> try {
> *seq.incrementAndGet();*
> }
> catch (ClusterTopologyException cte) {
> *cte.retryReadyFuture().get();*
> }
> }
>
> At the same time the *IgniteAtomicLong* doesn't throw such exception (at
> least I can't reproduce it).
>
> Please help me to clarify flowing questions:
> 1. Is it recommended to handle topology exception in the same way? Is there
> any public documentation about that?
> 2. What kind of distributed operations(cache updates, open data stream,
> atomic) are recommended to handle the ClusterTopologyException?
>
> --
>
> Regards
>
> Pavel Vinokurov
>
