camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Event driven configuration using Camel - Is it feasible or a misuse of the framework.
Date Sun, 09 Oct 2011 20:50:10 GMT
The problem with messaging is exactly that it does not hold state.  So 
if you need to use messaging you could make the sender repeat the 
message regularly so late subscribers would get it.
If several source can change the state that will not work.

If a central server is ok for you then a simple service would be good 
If not then a very good solution for your problem would be distributed 
cache like


Am 09.10.2011 19:52, schrieb Mark Doyle:
> 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.
> Example:
> 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

Christian Schneider

Open Source Architect

View raw message