Well, with this use case, if one of the nodes goes down, there is always a chance to lost notifications. I don't think that it's possible to recover lost notifications with out of the box solution, but if you will be able to track the last processed notification and store update time in entries, you will be able to find not processed entries. Otherwise, you will need to register CQ again and process all the entries using initialQuery.
Evgenii ср, 1 апр. 2020 г. в 13:16, narges saleh <snarges...@gmail.com>: > Thanks Evgenii for the recommendation and the heads up. > > Is there a way to recover the lost notifications or even know if a > notification is lost? > > On Wed, Apr 1, 2020 at 12:15 PM Evgenii Zhuravlev < > e.zhuravlev...@gmail.com> wrote: > >> Hi, >> >> 1) I would recommend checking ContinouousQuery.setLocal: >> https://www.gridgain.com/sdk/ce/latest/javadoc/org/apache/ignite/cache/query/Query.html#setLocal-boolean-. >> Please check if it fits your requirements. >> 2) You will need to do this in a separate thread, because cache >> operations shouldn't be used inside CQ listeners, as they are executed >> synchronously. >> >> In case of using local CQ, there is a chance to miss notifications in >> case of node failure, it's described in javadoc. >> >> Evgenii >> >> >> вт, 31 мар. 2020 г. в 03:00, narges saleh <snarges...@gmail.com>: >> >>> Hi All, >>> I'd like to get your feedback regarding the following pattern. >>> >>> 1) CQ setup that listens to the changes to a cache on the local node >>> only. >>> 2) Upon receiving notification on a change, the listener makes additions >>> to two other caches, one being on the local node (partitioned) and the >>> other cache being replicated across all the nodes in the cluster. >>> >>> Is this setup performant and reliable in terms of the data staying in >>> sync across the cluster? >>> >>> thanks. >>> >>> >>>
