Val, Thanks for the feedback.
Essentially what I really want in Ignite.Net version of the Ignite distributed Queue with local consumers on each server reading and processing just the elements that server is responsible for (which may be a slight mangling of queue semantics...) I have written a code POC that does create a CQ on each server node and restricts itself to reading local elements for the cache. This doesn't abuse the remote filters so much, but I have been pondering the best practice for establishing the service initially from a practical perspective. With the single CQ approach, the remote filters are really just shunting the cache items into another class that performs asynchronous processing of them, so locking should not be a significant problem. However, the different remote filters aspects for the initial scan and continuous query elements mean there needs to be some sleight of hand to ensure the asynchronous processing context gets fed correctly from both. I was not aware of the 'deliver once' guarantee only being relevant to the local filter. While my processing is idempotent, it's still not a good idea to reprocess things unnecessarily. Given a service deployment seems appropriate either way I might look again at per-node grid service deployment of a CQ operating locally on cache elements so as to remove potential abuse of the remote filter. Thanks, Raymond. -----Original Message----- From: vkulichenko [mailto:valentin.kuliche...@gmail.com] Sent: Friday, April 27, 2018 5:49 AM To: user@ignite.apache.org Subject: RE: Using a cache as an affinity co-located processing buffer in Ignite.Net Raymond, If you want to have a single continuous query on one of the server nodes, then I think singleton service is the best option to achieve that. It will not only guarantee that there is one query at a time, but will also make sure to redeploy it in case of failure. Also I would be accurate with doing processing in the remote filter. Filter is not designed for this, it's designed to do the filtering of updates before sending them to listening node. Major pitfall here is that it's invoked within entry lock, so any heavy processing would block the entry. Moreover, synchronous cache or other operations can cause deadlocks and/or thread starvation. Finally, keep in mind that filter can be invoked multiple times (at least for primary and backups, sometimes even more in case of failures). There is no exactly-once guarantee for remote filter, it's only applied to local listener. -Val -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
