Re: EntryProcessor invoked twice

2015-12-03 Thread Valentin Kulichenko
I created the ticket for this issue:
https://issues.apache.org/jira/browse/IGNITE-2083

Alexey G., can you please share your thoughts in this ticket?

-Val

On Thu, Dec 3, 2015 at 2:56 PM, Andrey Kornev 
wrote:

> Dmitriy,
>
> Alexey's point is just an explanation of the existing implementation and
> not how it is supposed to be.  And while nobody really knows what the
> correct behavior should be, the one implemented by Ignite is incredibly
> over-engineered. As I argued in a different thread, other vendors provide
> more reasonable implementations and their users seem to be quite content
> with the performance.
>
> Cheers
> Andrey
>
> > From: dsetrak...@gridgain.com
> > Date: Thu, 3 Dec 2015 10:35:34 -0800
> > Subject: Re: EntryProcessor invoked twice
> > To: dev@ignite.apache.org
> >
> > Point taken.
> >
> > However I still don’t get why it should be called twice in PESSIMISTIC
> > mode. Can someone explain?
> >
> > D.
> >
> > On Thu, Dec 3, 2015 at 10:04 AM, Andrey Gura  wrote:
> >
> > > Hi,
> > >
> > > Recently Alexey Goncharuk wrote in thread "EntryProcessor execution
> > > semantics":
> > >
> > > For example, in a case of explicit optimistic
> > > > READ_COMMITTED transaction it may be called more than once because
> Ignite
> > > > needs to calculate a return value for the first invoke() and then it
> > > should
> > > > be called second time during commit when transactional locks are
> held.
> > >
> > >
> > > Current requirement is that an EntryProcessor should be a stateless
> > > > function, and it may be called more than once (but of course it will
> > > > receive the same cache value every time).
> > > >
> > >
> > >
> > >
> > > On Thu, Dec 3, 2015 at 8:46 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Dmitry,
> > > >
> > > > Counter will not be incremented twice, because the entry is locked
> and EP
> > > > is guaranteed to be called both times for the same old value. So
> there is
> > > > no critical bug here in my view, but I just don't see the reason why
> we
> > > > call it two times instead of one for one operation.
> > > >
> > > > -Val
> > > >
> > > > On Thu, Dec 3, 2015 at 1:22 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > I think this is definitely a bug. Imagine that EP is used to
> maintain a
> > > > > counter, and the counter is incremented with every update. In this
> case
> > > > the
> > > > > counter will be updated 2 times instead of 1.
> > > > >
> > > > > Alexey G., would be nice to hear your thoughts here.
> > > > >
> > > > > D.
> > > > >
> > > > > On Wed, Dec 2, 2015 at 9:08 PM, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com> wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I noticed that when I execute cache.invoke() in transactional
> cache,
> > > > it's
> > > > > > invoked twice for the same old value on the primary node. First
> > > > > invocation
> > > > > > is done on prepare step [1], the second one happens on commit
> [2]. Is
> > > > > this
> > > > > > expected behavior? Why can't we reuse already calculated new
> value
> > > > during
> > > > > > commit?
> > > > > >
> > > > > > [1]
> > > > > > java.lang.RuntimeException: XXX
> > > > > > at
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:106)
> > > > > > at
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:96)
> > > > > > at
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> org.apache.ignite.internal.processors.cache.

RE: EntryProcessor invoked twice

2015-12-03 Thread Andrey Kornev
Dmitriy,

Alexey's point is just an explanation of the existing implementation and not 
how it is supposed to be.  And while nobody really knows what the correct 
behavior should be, the one implemented by Ignite is incredibly 
over-engineered. As I argued in a different thread, other vendors provide more 
reasonable implementations and their users seem to be quite content with the 
performance.

Cheers
Andrey

> From: dsetrak...@gridgain.com
> Date: Thu, 3 Dec 2015 10:35:34 -0800
> Subject: Re: EntryProcessor invoked twice
> To: dev@ignite.apache.org
> 
> Point taken.
> 
> However I still don’t get why it should be called twice in PESSIMISTIC
> mode. Can someone explain?
> 
> D.
> 
> On Thu, Dec 3, 2015 at 10:04 AM, Andrey Gura  wrote:
> 
> > Hi,
> >
> > Recently Alexey Goncharuk wrote in thread "EntryProcessor execution
> > semantics":
> >
> > For example, in a case of explicit optimistic
> > > READ_COMMITTED transaction it may be called more than once because Ignite
> > > needs to calculate a return value for the first invoke() and then it
> > should
> > > be called second time during commit when transactional locks are held.
> >
> >
> > Current requirement is that an EntryProcessor should be a stateless
> > > function, and it may be called more than once (but of course it will
> > > receive the same cache value every time).
> > >
> >
> >
> >
> > On Thu, Dec 3, 2015 at 8:46 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Dmitry,
> > >
> > > Counter will not be incremented twice, because the entry is locked and EP
> > > is guaranteed to be called both times for the same old value. So there is
> > > no critical bug here in my view, but I just don't see the reason why we
> > > call it two times instead of one for one operation.
> > >
> > > -Val
> > >
> > > On Thu, Dec 3, 2015 at 1:22 AM, Dmitriy Setrakyan  > >
> > > wrote:
> > >
> > > > I think this is definitely a bug. Imagine that EP is used to maintain a
> > > > counter, and the counter is incremented with every update. In this case
> > > the
> > > > counter will be updated 2 times instead of 1.
> > > >
> > > > Alexey G., would be nice to hear your thoughts here.
> > > >
> > > > D.
> > > >
> > > > On Wed, Dec 2, 2015 at 9:08 PM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > I noticed that when I execute cache.invoke() in transactional cache,
> > > it's
> > > > > invoked twice for the same old value on the primary node. First
> > > > invocation
> > > > > is done on prepare step [1], the second one happens on commit [2]. Is
> > > > this
> > > > > expected behavior? Why can't we reuse already calculated new value
> > > during
> > > > > commit?
> > > > >
> > > > > [1]
> > > > > java.lang.RuntimeException: XXX
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> > com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:106)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> > com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:96)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:381)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:909)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:527)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> > org.apache.ignite.internal.processors.cache.distributed.dht.G

Re: EntryProcessor invoked twice

2015-12-03 Thread Dmitriy Setrakyan
Point taken.

However I still don’t get why it should be called twice in PESSIMISTIC
mode. Can someone explain?

D.

On Thu, Dec 3, 2015 at 10:04 AM, Andrey Gura  wrote:

> Hi,
>
> Recently Alexey Goncharuk wrote in thread "EntryProcessor execution
> semantics":
>
> For example, in a case of explicit optimistic
> > READ_COMMITTED transaction it may be called more than once because Ignite
> > needs to calculate a return value for the first invoke() and then it
> should
> > be called second time during commit when transactional locks are held.
>
>
> Current requirement is that an EntryProcessor should be a stateless
> > function, and it may be called more than once (but of course it will
> > receive the same cache value every time).
> >
>
>
>
> On Thu, Dec 3, 2015 at 8:46 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Dmitry,
> >
> > Counter will not be incremented twice, because the entry is locked and EP
> > is guaranteed to be called both times for the same old value. So there is
> > no critical bug here in my view, but I just don't see the reason why we
> > call it two times instead of one for one operation.
> >
> > -Val
> >
> > On Thu, Dec 3, 2015 at 1:22 AM, Dmitriy Setrakyan  >
> > wrote:
> >
> > > I think this is definitely a bug. Imagine that EP is used to maintain a
> > > counter, and the counter is incremented with every update. In this case
> > the
> > > counter will be updated 2 times instead of 1.
> > >
> > > Alexey G., would be nice to hear your thoughts here.
> > >
> > > D.
> > >
> > > On Wed, Dec 2, 2015 at 9:08 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Igniters,
> > > >
> > > > I noticed that when I execute cache.invoke() in transactional cache,
> > it's
> > > > invoked twice for the same old value on the primary node. First
> > > invocation
> > > > is done on prepare step [1], the second one happens on commit [2]. Is
> > > this
> > > > expected behavior? Why can't we reuse already calculated new value
> > during
> > > > commit?
> > > >
> > > > [1]
> > > > java.lang.RuntimeException: XXX
> > > > at
> > > >
> > > >
> > >
> >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:106)
> > > > at
> > > >
> > > >
> > >
> >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:96)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:381)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:909)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:527)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:822)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:462)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:406)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareTx(IgniteTxHandler.java:200)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:101)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:114)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:112)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> > > > at
> > > >
> > > >
> > >
> >
> org.apach

Re: EntryProcessor invoked twice

2015-12-03 Thread Andrey Gura
Hi,

Recently Alexey Goncharuk wrote in thread "EntryProcessor execution
semantics":

For example, in a case of explicit optimistic
> READ_COMMITTED transaction it may be called more than once because Ignite
> needs to calculate a return value for the first invoke() and then it should
> be called second time during commit when transactional locks are held.


Current requirement is that an EntryProcessor should be a stateless
> function, and it may be called more than once (but of course it will
> receive the same cache value every time).
>



On Thu, Dec 3, 2015 at 8:46 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Dmitry,
>
> Counter will not be incremented twice, because the entry is locked and EP
> is guaranteed to be called both times for the same old value. So there is
> no critical bug here in my view, but I just don't see the reason why we
> call it two times instead of one for one operation.
>
> -Val
>
> On Thu, Dec 3, 2015 at 1:22 AM, Dmitriy Setrakyan 
> wrote:
>
> > I think this is definitely a bug. Imagine that EP is used to maintain a
> > counter, and the counter is incremented with every update. In this case
> the
> > counter will be updated 2 times instead of 1.
> >
> > Alexey G., would be nice to hear your thoughts here.
> >
> > D.
> >
> > On Wed, Dec 2, 2015 at 9:08 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Igniters,
> > >
> > > I noticed that when I execute cache.invoke() in transactional cache,
> it's
> > > invoked twice for the same old value on the primary node. First
> > invocation
> > > is done on prepare step [1], the second one happens on commit [2]. Is
> > this
> > > expected behavior? Why can't we reuse already calculated new value
> during
> > > commit?
> > >
> > > [1]
> > > java.lang.RuntimeException: XXX
> > > at
> > >
> > >
> >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:106)
> > > at
> > >
> > >
> >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:96)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:381)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:909)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:527)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:822)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:462)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:406)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareTx(IgniteTxHandler.java:200)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:101)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:114)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:112)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> > > at
> > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > > at
> > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > > at java.lang.Thread.run(Thread.java:745)
> > >
> 

Re: EntryProcessor invoked twice

2015-12-03 Thread Valentin Kulichenko
Dmitry,

Counter will not be incremented twice, because the entry is locked and EP
is guaranteed to be called both times for the same old value. So there is
no critical bug here in my view, but I just don't see the reason why we
call it two times instead of one for one operation.

-Val

On Thu, Dec 3, 2015 at 1:22 AM, Dmitriy Setrakyan 
wrote:

> I think this is definitely a bug. Imagine that EP is used to maintain a
> counter, and the counter is incremented with every update. In this case the
> counter will be updated 2 times instead of 1.
>
> Alexey G., would be nice to hear your thoughts here.
>
> D.
>
> On Wed, Dec 2, 2015 at 9:08 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Igniters,
> >
> > I noticed that when I execute cache.invoke() in transactional cache, it's
> > invoked twice for the same old value on the primary node. First
> invocation
> > is done on prepare step [1], the second one happens on commit [2]. Is
> this
> > expected behavior? Why can't we reuse already calculated new value during
> > commit?
> >
> > [1]
> > java.lang.RuntimeException: XXX
> > at
> >
> >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:106)
> > at
> >
> >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:96)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:381)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:909)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:527)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:822)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:462)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:406)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareTx(IgniteTxHandler.java:200)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:101)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:114)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:112)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> > at
> >
> >
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> > at
> >
> >
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> > at
> >
> >
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> >
> > [2]
> > java.lang.RuntimeException: XXX
> > at
> >
> >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:106)
> > at
> >
> >
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:96)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.applyTransformClosures(IgniteTxAdapter.java:1314)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:826)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.finish(GridDhtTxLocalAdapter.java:836)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finish(GridDhtTxLocal.java:657)
> > at
> >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.co

Re: EntryProcessor invoked twice

2015-12-03 Thread Dmitriy Setrakyan
I think this is definitely a bug. Imagine that EP is used to maintain a
counter, and the counter is incremented with every update. In this case the
counter will be updated 2 times instead of 1.

Alexey G., would be nice to hear your thoughts here.

D.

On Wed, Dec 2, 2015 at 9:08 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Igniters,
>
> I noticed that when I execute cache.invoke() in transactional cache, it's
> invoked twice for the same old value on the primary node. First invocation
> is done on prepare step [1], the second one happens on commit [2]. Is this
> expected behavior? Why can't we reuse already calculated new value during
> commit?
>
> [1]
> java.lang.RuntimeException: XXX
> at
>
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:106)
> at
>
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:96)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:381)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:909)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:527)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:822)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:462)
> at
>
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:406)
> at
>
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareTx(IgniteTxHandler.java:200)
> at
>
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:101)
> at
>
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:114)
> at
>
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:112)
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at
>
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
>
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
>
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
> [2]
> java.lang.RuntimeException: XXX
> at
>
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:106)
> at
>
> com.workday.fabric.ScratchClient$ScratchEntryProcessor.process(ScratchClient.java:96)
> at
>
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.applyTransformClosures(IgniteTxAdapter.java:1314)
> at
>
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:826)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.finish(GridDhtTxLocalAdapter.java:836)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finish(GridDhtTxLocal.java:657)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitAsync(GridDhtTxLocal.java:557)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:574)
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:95)
> at
>
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:260)
> at
>
> org.apache.ignite.internal.util.future.GridCompoundFuture.access$700(GridCompoundFuture.java:43)
> at
>
> org.apache.ignite.internal.util.future.GridCompoundFuture$Listener