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 <[email protected]> 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
