Thanks Alexey,
I will consider an option to get familiar more deeply with product and
contribute some patch.
2016-03-04 1:03 GMT+02:00 Alexey Goncharuk :
> Myron,
>
> I believe IGNITE-2645 should be fixed in the near future since the issue
> is critical, and will definitely be included to 1.6.
>
Myron,
I believe IGNITE-2645 should be fixed in the near future since the issue is
critical, and will definitely be included to 1.6.
As for the IGNITE-1018, I will not speculate on the timelines because the
issue has some workarounds, even though it is possible that it will be
fixed for 1.6 if so
Alexey,
Thanks for advice.
But could you also provide any timelines for listed issues?
2016-03-02 1:14 GMT+02:00 Alexey Goncharuk :
> Oh, I see now what you mean, IGNITE-1018 has escaped my view. Then, until
> IGNITE-1018 is fixed, the only guaranteed approach is to wait on a CDL.
> Here is t
Oh, I see now what you mean, IGNITE-1018 has escaped my view. Then, until
IGNITE-1018 is fixed, the only guaranteed approach is to wait on a CDL.
Here is the pseudo-code that I have in mind:
LifecycleBean or after Ignition.start():
// Populate your node local map
CountDownLatch init = nlm.ge
Alexey,
My initial approach was to put reference into NodeLocalMap after "start"
method since I saw no other possibility to do that since I was a little bit
bit confused of - https://issues.apache.org/jira/browse/IGNITE-1018.
But then I tried to go with LifecycleBean but with AFTER_NODE_START.
So
Myron,
What approach did you use initially to initialize the node local map?
IgniteNode is considered to be fully functional as soon as Ignition.start()
method returns control, so any operations done on NodeLocalMap after the
node start should be considered to be run concurrently with EntryProcess
Hello Team,
Seems like I've found the root cause of such behavior.
My EntryProcessor is getting local node resource (actually spring bean).
But since resource injection is not supported for EntryProcessor yet
(please correct me if I am wrong) I have made a workaround of getting named
grid instance
Alexey,
For now, I've only figured out that problem is on node that is joining the
grid and with records/keys for which it becomes primary.
Also I tried different rebalance modes but with no luck. But now I can
confirm that "cacheStore" makes no impact on that (tried to disable
cacheStore and resu
Myron,
We have a specific test for the exact use-case you have described and it
passes - see IgniteAtomicCacheEntryProcessorNodeJoinTest. I tried to play
with the configuration (added test store, tried different memory modes),
but was not able to make the test fail.
Is there any change you can sh
Hello team,
Could you please provide your input on that?
Thanks,
2016-02-25 16:28 GMT+02:00 Myron Chelyada :
> Hello Team,
>
> Looks like I am faced to similar issue in case of cache rebalancing.
> I.e. there are few nodes and cache data are being modified/updated via
> EntryProcessor. And at
Hello Team,
Looks like I am faced to similar issue in case of cache rebalancing.
I.e. there are few nodes and cache data are being modified/updated via
EntryProcessor. And at some moment additional node is joined to grid.
And finally (after rebalance complete and update complete) I got cache
valu
Will try to apply some workaround and looking forward to fix.
2016-02-12 16:58 GMT+02:00 Alexey Goncharuk :
> Myron,
>
> Thank you for reporting the issue. The assertion happens when the value is
> present in the store, absent in the cache and you run invokeAll(). As a
> temporary solution, you c
Myron,
Thank you for reporting the issue. The assertion happens when the value is
present in the store, absent in the cache and you run invokeAll(). As a
temporary solution, you can either call invoke() for each particular key
individually, or call getAll() for the keys prior to calling invokeAll(
So,
Please find test in attachment which allows to reproduce the issue.
It is very plain and much simpler than I initially described.
I was confused before because I was able to reproduce this issue on one
environment and couldn't on another. And the reason for that is that
assertion were not enab
Hi Alexey,
Will try to extract main logic into some test that would allow to reproduce
it.
But in meanwhile I figured out that issue appears only on cache that is
store backed. I.e. as soon as I set either "readThrough" or "writeThrough"
to "false" (or both) issue disappear.
But actually in my cas
Myron,
I tried to reproduce this assertion on ignite-1.5, but with no luck. Can
you share your full cache configuration, the number of nodes in your
clusterr and a code snippet allowing to reproduce the issue?
Thanks,
AG
Team,
Could you please provide some input on that?
I am blocked since it looks like EntryProcessor can't be used at all (at
least with PARTITIONED cache).
Thanks,
2016-02-09 15:57 GMT+02:00 Myron Chelyada :
> Hmm, doing the same but with:
>
> atomicWriteOrderMode=PRIMARY
>
> writeSynchronizatio
Hmm, doing the same but with:
atomicWriteOrderMode=PRIMARY
writeSynchronizationMode=PRIMARY_SYNC
causes:
[atomic.GridDhtAtomicCache] - Unexpected exception during cache
update
java.lang.AssertionError: Invalid version for inner update
[entry=GridDhtAtomicCacheEntry [super=GridDhtCacheEntry [r
Hi Alexey,
Thanks for reply.
Are there any other similar limitations with modes related to entry
processor?
Perhaps there is some detailed documentation (more detailed than I see on
site)?
2016-02-09 12:09 GMT+02:00 Alexey Goncharuk :
> Myron,
>
> This is a known usability issue, see [1]. You n
Myron,
This is a known usability issue, see [1]. You need to set
atomicWriterOrderMode to PRIMARY in order to make entry processors to work
correctly. I will cross-post this mail to devlist in order to raise the
ticket priority.
[1] https://issues.apache.org/jira/browse/IGNITE-2088
--AG
Hello team,
I am performing concurrent updates on the same entries in cache by using
EntryProcessor.
(Entry processor just sums existing values with provided delta values. I.e.
I have List of doubles as cache value).
And after performing such updates N times I expected to have final values
equal t
21 matches
Mail list logo
