3 ms·
I wouldn't call this a design flaw, it just shifts the responsibility of handling conflicts to the consumer app rather than forcing you into a server-side solut
by vladimirralev 11y ago
I wouldn't call this a design flaw, it just shifts the responsibility of handling conflicts to the consumer app rather than forcing you into a server-side solution. It's too application-specific what kind of partition recovery do you need. Most people don't mind to lose a message. If you don't want to lose messages (CP-mode?) just stick all clients for certain app object (AMQP tree) to consume from the same node and block until everything is healthy or fail them over in some app-specific way to ensure consistency. While other AMQP servers may handle it better for your case these things tend to be app-specifc since your app knows better than the server which trees are critical and which are not.
- atombender 11y agoI would definitely call it a design flaw. After all, RabbitMQ pretends to be multi-master; but if you set up clients to treat a single node (of several) as a master, the other nodes will be reduced to being dumb backup nodes. Also, don't forget that clients don't decide which node owns a queue — it's owned by the node where it's first created. Being consistent about always talking to the correct node, and keeping track of which node owns the master replica of any given queue, puts a complicating burden on both clients and the system administrator. You can run RabbitMQ without any partition handling, but that means the ops staff needs to wake up in the middle of the night to handle downtime. Not to mention that there's no queue merging support — at the very least, it could be possible to merge conflicting queues where you don't particularly care about ordering.