I found the RabbitMQ support shipped in 2.12 to be pretty sub-par for a bunch of reasons:
- host/port must be configured in the URI - vhost must be configured in the URI - autoDelete cannot be specified separately for the Exchange/Queue - durability cannot be specified separately for the Exchange/Queue - poor options around ack/nack (autoAck is the only exposed option, which seems dangerous to me and CAMEL-6767<https://issues.apache.org/jira/browse/CAMEL-6767> only addresses a current bug... which isn't taking exchange.isFailed() into account) - no options around redelivery on exchange failures I would think that all of those should probably be addressed in the current RabbitMQComponent/RabbitMQEndpoint/RabbitMQConsumer classes However, to make using RabbitMQ as a viable option for a classic queue use case, which is all I wanted to do, even fixing all of the above still left the URI's feeling quite heavy.. mainly because the standard AMQP practices around routing keys and anonymous queue bindings make perfect sense, unless, you just want durable non-autodeleted named queues So I created RabbitMQQueueComponent/Consumer/Endpoint implementations which make it behave like one may expect for regular queueing. You configure the one-time settings (host/port, defaults for durability etc on the component) and then you can just create routes like this: from(rabbitmq:exchange?queue=from queue).to(rabbitmq:exchange?queue=to queue) The component/endpoints/consumers take care of the creating matching routing keys, creating appropriate exchanges/queues/bindings using the AMQP client etc to make it act like classic queues I implemented everything mentioned above, but it would be competing with the existing RabbitMQ components (because, rightfully so, the default implementation would want to have AMQP semantics) So my question is just... is there any interest to have contributed components for RabbitMQ that have very opinionated default AMQP settings and behaviors -- Alexander Sherwin
