Hello, Igniters. I tried to implement IgniteSet data recovery when persistence enabled [1] using trivial cache scanning, however I cannot find optimal way to do that because of the following reasons: - Performing operations on IgniteSet requires completion of data loading (restoring of setDataMap) on all nodes. Do this during partition map exchange is too long. - The prohibition of operations on IgniteSet before the completion of asynchronous cache scanning on all nodes looks rather complicated, because It is necessary to support all situations of unstable topology.
So I see one option to fix data loss on node restart - remove the entire optimization (setDataMap) and rework the iterator implementation to perform cache scanning. Thoughts? [1] https://issues.apache.org/jira/browse/IGNITE-5553 2018-03-17 8:20 GMT+03:00 Andrey Kuznetsov <stku...@gmail.com>: > Thanks, Dmitry. I agree ultimately, DS API uniformity is a weighty reason. > > 2018-03-17 3:54 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > >> On Fri, Mar 16, 2018 at 7:39 AM, Andrey Kuznetsov <stku...@gmail.com> >> wrote: >> >> > Dmitry, your way allows to reuse existing {{Ignite.set()}} API to create >> > both set flavors. We can adopt it unless somebody in the community >> objects. >> > Personally, I like {{IgniteCache.asSet()}} approach proposed by Vladimir >> O. >> > more, since it emphasizes the difference between sets being created, but >> > this will require API extension. >> > >> >> Andrey, I am suggesting that Ignite.set(...) in non-collocated mode behaves >> exactly the same as the proposed IgniteCache.asSet() method. I do not like >> the IgniteCache.asSet() API because it is inconsistent with Ignite data >> structure design. All data structures are provided on Ignite API directly >> and we should not change that. >> >> D. >> > > > > -- > Best regards, > Andrey Kuznetsov.
