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 and then fetching resource from "nodeLocalMap" there. And again since there is no possibility to initialize nodeLocalMap via IgniteConfiguration (similar to have lifecycle beans and/or local vent listeners) I've done some workaround to put data there on startup. And finally I am faced to issue when nodeLocalMap is not initialized yet but node is already getting EntryProcessors from other nodes (i.e. invokeAll on other nodes). And it was a very big surprise for me that there is no any exception nor error/warning within log files (and thats why I spent a lot of time on finding the root cause). So my question is shouldn't such error should be logged? Also as a fix I tried to use lifecycle bean now which is actually putting resources into nodeLocalMap and my preliminary tests passed. But my question is how reliable is such approach, are there perhaps some edge cases? Finally (since I've touched resource injection chapter), what are the plans of adding resource injection support for EntryProcessor and nodeLocalMap initialization/availability (I saw some related issues in Jira)?
Thanks, 2016-02-29 18:20 GMT+02:00 Myron Chelyada <[email protected]>: > 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 result is the same). > The other thing I am observing is that "innerUpdate" is being actually > called but update is not applied. Will try to capture more information > and/or build/extract some test code that would allow to reproduce it. > But meanwhile if provide above information would provide you some hints > and allow you to see/find the root cause that would be awesome. > > Thanks, > Myron > > 2016-02-29 1:13 GMT+02:00 Alexey Goncharuk <[email protected]>: > >> 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 share a reproducible example as you did >> before for the issue with the assertion you've encountered? >> >> Thanks, >> AG >> > >
