While this does seem like an application concern... I think rolling back probably makes sense. More generally how are you planning on dealing with inconsistent state between brokers? What if one of the instances is temporarily off-line when a new queue is created... or what if you want to add a new broker to your cluster? Are you planning on building tooling to bring brokers into line with the existing state? How are you determining the "current" state if you have brokers that disagree?
-- Rob On 4 February 2017 at 07:10, Rawad Assaf <[email protected]> wrote: > Hello, > > I have a use case where the dispatch router should be used with an array of > brokers to provide a scalable distributed work queue. > > The queue should be created at runtime using a management API that creates > the queue across all the brokers and advertise it at the level of the > Dispatch router. > > My question concerns the transactionality of the above creation. What > happens if the operation succeeds only on a subset of the brokers? Should > we rollback the operation to ensure all the brokers remain in a consistant > state? > > There's a good chance this is an "application" concern but I was wondering > if I you have any recommendation for the above question. > > Best regards, > Rawad >
