Hello! Actually, delaying joining the cluster is complex enough since it will add a lot of unexpected concerns.
There are ClusterGroup's precisely for that purpose. Regards, -- Ilya Kasnacheev пт, 11 янв. 2019 г. в 15:58, Lukas Polacek <[email protected]>: > Hi, > we already do that by using an IgniteSet which contains consistent IDs of > the nodes that are ready, but it's very error-prone and unnecessarily > complex. Delaying joining the cluster would make everything simpler. > > On Thu, Jan 10, 2019 at 1:38 PM Ilya Kasnacheev <[email protected]> > wrote: > >> Hello! >> >> I think you should decouple workload readiness from joining the cluster. >> >> You should let node join cluster first, then iterate entries, and only >> then allow workload to this node. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> чт, 3 янв. 2019 г. в 13:18, Lukas Polacek <[email protected] >> >: >> >>> Hi, >>> in our use case we need to run some C++ code (via JNI) whenever >>> something is pushed into the local Ignite cache. In other words, we need to >>> have Ignite in sync with C++ memory. We have a local listener that listens >>> to EVT_CACHE_OBJECT_PUT events and executes the C++ code, so everything is >>> fine while the node is running. However, we use native persistence, so >>> after a node restart, the local cache is read from the disk but the C++ >>> code hasn't been run for any cache entries, which means that Ignite and C++ >>> memory are out of sync. >>> >>> Iterating through the local cache entries is only possible once the node >>> has already joined the cluster, but that's too late for us - it needs to be >>> done before joining the cluster. >>> >>> I've managed to add a lifecycle bean event BEFORE_CLUSTER_JOIN (see >>> http://apache-ignite-users.70518.x6.nabble.com/Register-listeners-before-joining-the-cluster-tc25944.html, >>> a PR is hopefully coming soon), which is triggered before joining the >>> cluster but at that point we cannot access the cache via >>> ignite.cache(...). Is there a way to access all entries in the native >>> persistence at that point or earlier? I'm also fine with modifying the >>> Ignite source code if that's necessary (and simple enough), since we are >>> just prototyping. >>> >>
