I think you’d want to have at least two persistent nodes, or the loss of a single node could take down your whole service.
> On 14 Jun 2021, at 15:51, Krish <kishanthesiy...@gmail.com> wrote: > > Background on Use case: We have around 10000 tasks that we want to run across > ignite cluster. These tasks will be submitted by multiple independent client > nodes. Each task will have a priority and task key. Two tasks with the same > taskKey should not be running in parallel. Execution of all the tasks should > be based on priority. As far as I know, ignite does not provide locking > between two tasks and it does not provide a way to distribute tasks based on > its priority *across *the cluster. > > To meet the above requirements, we have a cluster singleton monitoring > ignite service which will create the compute tasks and distribute them > across the cluster. It will take care of priority and locking. All clients > will create a cache object(based on which service can create actual compute > tasks) and store it in the cache store. Service will query the cache-store > to find the next set of valid tasks based on priority and locking. > > We need native persistence because even if the cluster goes down, it should > not lose the tasks that were sent by the clients. And only ignite service > will be dealing with these task objects, we are thinking of enabling it only > for the cluster node on which our ignite service is hosted. > > Let me know if this makes sense or if you see any red flags. > > Thanks, > Krish > > > > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
