camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Doyle <>
Subject Re: Event driven configuration using Camel - Is it feasible or a misuse of the framework.
Date Sun, 09 Oct 2011 17:52:21 GMT
Hi Christian,

Thanks for the input. I was, perhaps mistakenly, using the term Channel as a
generic term for all queues, topics and the like.

The more I think about it, the more I think a simple publish subscribe
set-up (e.g. a JMS Topic) would work if it had one strange addition, that
is, the message persists and will be read by late subscribers.

Source creates topic a publishes message M1. Clients A and B subscribe and
receive M1. Later, Source publishes M2. Client A and B received M2. M1 is no
longer important. Client C subscribes and receives M2 even though Client A
and B have already received it (it persists).

Durability isn't important in the traditional sense as old messages will not
be interesting to clients. Imagine the message as something which describes
the current state of the system, if that changes, clients need
to adjust their behaviour.

It's the late subscribers which is the problem I think.

On 8 October 2011 15:16, Christian Schneider <>wrote:

> I donĀ“t think a channel is a solution for this problem. A channel tpyically
> is message oriented so one sends the message into the channel, one or more
> receivers
> receive it. You typically can not query a channel for information.
> Can you explain more about your use case? Are your clients local to the
> config store or remote?
> What is your environment. OSGi? Servlet? Standalone?
> I ask because there may be more suitable solutions depending on  your
> requirements.
> In OSGi the config admin service is the obvious solution. By default it is
> not remote capable though.
> In JMS you could use a topic with durable subscribers. Every config change
> could bee sent to the topic. The subscribers would then drain their
> messages and use the information from the last message.
> Another option is to use a webservice or rest service. One call to update
> and one call to read the config.
> Christian
> Am 08.10.2011 09:41, schrieb Mark Doyle:
>  Is there a pattern which will allow us to send a single message to a
>> channel
>> which will then persist.The source can replace the message simply by
>> sending
>> another one, this means the latest message is the only important one.  The
>> channel can have many subscribers and any late subscribers should pick up
>> the latest message.
>> The use case is a kind of dynamic configuration where clients can pick up
>> the interesting config data from a message in a channel. I'm not sure if
>> this is a misuse of Camel though, or whether it's simple not applicable
>> for
>> all Camel components. It;s worth noting that the clients only need the
>> message once to work. If they channel is not available they simply don't
>> get
>> updates.
> --
> Christian Schneider
> Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message