ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinokurov Pavel <vinokurov.pa...@gmail.com>
Subject Re: Atomic sequence and topology exception
Date Thu, 15 Mar 2018 13:36:48 GMT
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.goncharuk@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.spb@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.pasha@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message