Re: EntryProcessor invoked twice
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
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
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
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
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
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