camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Is there interest in a second RabbitMQ component/consumer/endpoint?
Date Mon, 18 Nov 2013 10:30:35 GMT

I dont think its a good idea to create a 2nd component. Instead
improve/fix make the the existing component better.

We love contributions

On Fri, Nov 15, 2013 at 7:49 PM, Christian Posta
<> wrote:
> 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

Claus Ibsen
Red Hat, Inc.
Twitter: davsclaus
Author of Camel in Action:

View raw message