camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Implementing Publish Subscribe Channel
Date Wed, 09 Dec 2009 05:27:23 GMT
Hi Hendry

I am a bit busy over the next week or so, due to new book deadline and
a other engagements.

However I haven't forgotten about this use-case and I think we can
improve the seda component
to let it support multiple consumers by sending a copy of the exchange
to each recipient.

Then you should be able to use it as a event broadcaster kinda thingy.

Fell free to create a ticket in JIRA



On Sun, Dec 6, 2009 at 6:50 PM, Hendy Irawan <hendy@soluvas.com> wrote:
>
> Hi Claus,
>
>
> Claus Ibsen-2 wrote:
>>
>> No seda does *not* support multiple consumers. Its meant to be used
>> with a single consumer only.
>> In 2.1 this is even enforced. Often end users had copy paste mistakes
>> and didnt want multiple consumers to the same seda endpoint.
>> Hence why we enforced this now in 2.1.
>>
>> What is your use case sine you need this? I am interesting in what you
>> are trying to solve?
>>
>>
>> What you could do is to extend seda, and have support multiple
>> consumers and have the Exchange being copied before its handed out to
>> every
>> consumers.
>>
>> Mind that when you copy the Exchange / Message if the body is not a
>> simple type such as String then you may only copy a reference to it
>> and thus have multiple consumers work on it concurrently, and thus you
>> need to be aware of thread safety issues.
>>
>> And there is a new interface in Camel 2.1, MultipleConsumersSupport,
>> which indicates whether an endpoint supports multiple consumers or
>> not.
>> You need to implement this and return true in your own component.
>>
>
> I'm not sure if a separate component is needed for this, because from my
> experience the <multicast> element works fine. And that's what I'm trying to
> get, using the <multicast> functionality in a @Consume'r.
>
> Maybe something like this (proposal):
>
> @Consume(uri="someuri", multicast=true)
>
> My use case is using Camel as event publisher. Exactly like Spring
> Application Events.
>
> @EndpointInject(uri="seda:events.form")
> ProducerTemplate formEvents;
>
> ...
> formEvents.sendBody(new FormEvent(...));
> ...
>
> then there are one or more event Listeners like this:
>
> @Consume(uri="seda:events.form")
> public void handleFormEvent(FormEvent event) { ... }
>
> BTW, the producer and consumer URI may not be the same. i.e. the publisher
> of the event may route it in some way and there may be multiple producers.
> However as far as consumers are concerned, they have this inbox URI (e.g.
> "seda:events.form") that all events will come together. Then multiple
> consumers can process the messages (it's InOnly, no need to reply).
>
> I can do this with <multicast>, but my "problem" is that I want it to be
> "dynamic" i.e. just @Consume annotation is needed, no change in routes.
> Because the consumers can be created and disposed dynamically.
> --
> View this message in context: http://old.nabble.com/Implementing-Publish-Subscribe-Channel-tp26654086p26667205.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



-- 
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Mime
View raw message