Hi Pavel, would you like to prepare fix/PR for this ticket?
Sincerely, Dmitriy Pavlov чт, 15 мар. 2018 г. в 16:36, Vinokurov Pavel <vinokurov.pa...@gmail.com>: > 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 <alexey.goncha...@gmail.com>: > > > 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 > > > > > > > > > -- > > Regards > > Pavel Vinokurov >
