The queue can be a good alternative [1] but the application has to care about faults handling. For example, if a client reads a message from the queue, starts doing some job as the message prescribes and then fails in the middle, then the job is incomplete and nobody else can pick it up. So, you would need to track somewhere else that the message is in fact was fully processed (just toggle the status).
[1] https://apacheignite.readme.io/docs/queue-and-set#cache-queues-and-load-balancing - Denis On Sat, Jul 18, 2020 at 12:42 AM Devakumar J <mail2jdevaku...@gmail.com> wrote: > Hi Denis, > > Thanks for your reply. > > I will explore the custom implementation of remote filter for load > balancing. > > Also currently we dont use kafka in our tech stack, so we dont want to > introduce it just for this purpose. > > I was also checking ignite events and distributed message queue as an > alternative for Continuous Queries. > > Can we define setup like, > 1. Define distributed message queue across the cluster. > 2. Each server node publish the selective cache events to the queue. > 3. Client nodes consume the queue. > > So in this case as per my understanding on distributed queue, > a. Client nodes will get events in load balanced way. > b. If any one client node down then other node will start consuming > all the events. > c. If both client nodes down, queue will still have the entries that > are not yet consumed as it is persisted. So if client nodes come up, it > will > resume from where it left. > > Is this feasible or do you see any issue in setup in case of server node > failure/ server node re-balancing. > > Thanks, > Devakumar J > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
