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 |
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 <[hidden email]> Date: вт, 13 мар. 2018 г. в 5:52 Subject: Atomic sequence and topology exception To: <[hidden email]> 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 |
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 <[hidden email]>: > 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 <[hidden email]> > Date: вт, 13 мар. 2018 г. в 5:52 > Subject: Atomic sequence and topology exception > To: <[hidden email]> > > > 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 > |
Alexey,
Thank you for your explanation. I have created the ticket https://issues.apache.org/jira/browse/IGNITE-7968 with attached reproducer. 2018-03-15 10:23 GMT+03:00 Alexey Goncharuk <[hidden email]>: > 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 <[hidden email]>: > > > 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 <[hidden email]> > > Date: вт, 13 мар. 2018 г. в 5:52 > > Subject: Atomic sequence and topology exception > > To: <[hidden email]> > > > > > > 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 > > > -- Regards Pavel Vinokurov |
Hi Pavel,
would you like to prepare fix/PR for this ticket? Sincerely, Dmitriy Pavlov чт, 15 мар. 2018 г. в 16:36, Vinokurov Pavel <[hidden email]>: > Alexey, > > Thank you for your explanation. > I have created the ticket > https://issues.apache.org/jira/browse/IGNITE-7968 > with attached reproducer. > > 2018-03-15 10:23 GMT+03:00 Alexey Goncharuk <[hidden email]>: > > > 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 <[hidden email]>: > > > > > 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 <[hidden email]> > > > Date: вт, 13 мар. 2018 г. в 5:52 > > > Subject: Atomic sequence and topology exception > > > To: <[hidden email]> > > > > > > > > > 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 > > > > > > > > > -- > > Regards > > Pavel Vinokurov > |
Free forum by Nabble | Edit this page |