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 <ch...@die-schneider.net>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 > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
