camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Sherwin <>
Subject Is there interest in a second RabbitMQ component/consumer/endpoint?
Date Fri, 15 Nov 2013 17:28:21 GMT
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<> only
   addresses a current bug... which isn't taking exchange.isFailed() into
   - 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

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message