Return-Path: 
 <users-return-10165-apmail-camel-users-archive=camel.apache.org@camel.apache.org>
Delivered-To: apmail-camel-users-archive@www.apache.org
Received: (qmail 36455 invoked from network); 6 Dec 2009 17:50:59 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 6 Dec 2009 17:50:59 -0000
Received: (qmail 20071 invoked by uid 500); 6 Dec 2009 17:50:58 -0000
Delivered-To: apmail-camel-users-archive@camel.apache.org
Received: (qmail 19994 invoked by uid 500); 6 Dec 2009 17:50:58 -0000
Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@camel.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@camel.apache.org>
List-Post: <mailto:users@camel.apache.org>
List-Id: <users.camel.apache.org>
Reply-To: users@camel.apache.org
Delivered-To: mailing list users@camel.apache.org
Received: (qmail 19984 invoked by uid 99); 6 Dec 2009 17:50:57 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Dec 2009 17:50:57 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Dec 2009 17:50:48 +0000
Received: from isper.nabble.com ([192.168.236.156])
	by kuber.nabble.com with esmtp (Exim 4.63)
	(envelope-from <lists@nabble.com>)
	id 1NHLFb-0001rl-HP
	for users@camel.apache.org; Sun, 06 Dec 2009 09:50:27 -0800
Message-ID: <26667205.post@talk.nabble.com>
Date: Sun, 6 Dec 2009 09:50:27 -0800 (PST)
From: Hendy Irawan <hendy@soluvas.com>
To: users@camel.apache.org
Subject: Re: Implementing Publish Subscribe Channel
In-Reply-To: <5380c69c0912060813o1189274fm6f1b8f71022a22b8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: hendy@soluvas.com
References: <26654086.post@talk.nabble.com>
 <5380c69c0912060358n674dcb57p6ea96ee0332642e3@mail.gmail.com>
 <26666101.post@talk.nabble.com>
 <5380c69c0912060813o1189274fm6f1b8f71022a22b8@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org


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.