camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Posta <>
Subject Re: Is there interest in a second RabbitMQ component/consumer/endpoint?
Date Fri, 15 Nov 2013 18:49:07 GMT
not sure what the rest of the community thinks... but i would say at
least put it on github :)
would it be possible to just auto-default to the "opinionated" config
settings in the current component?

On Fri, Nov 15, 2013 at 10:28 AM, Alex Sherwin <> wrote:
> 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
>    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

Christian Posta
twitter: @christianposta

View raw message