Atomic sequence and topology exception

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Atomic sequence and topology exception

Vinokurov Pavel
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
Reply | Threaded
Open this post in threaded view
|

Fwd: Atomic sequence and topology exception

Dmitriy Pavlov
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
Reply | Threaded
Open this post in threaded view
|

Re: Atomic sequence and topology exception

Alexey Goncharuk
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Atomic sequence and topology exception

Vinokurov Pavel
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
Reply | Threaded
Open this post in threaded view
|

Re: Atomic sequence and topology exception

Dmitriy Pavlov
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
>