If you like the JMS delivery model and you are using ActiveMQ as your message broker, you could subscribe to the topic as a retroactive consumer [1] and apply a "Last Image Subscription Policy" [2] on the broker to ensure that your subscribers receive the most recent message that was sent on the topic when they connect / subscribe.
1. http://activemq.apache.org/retroactive-consumer.html <http://activemq.apache.org/retroactive-consumer.html>2. http://activemq.apache.org/subscription-recovery-policy.html <http://activemq.apache.org/subscription-recovery-policy.html>I'm sure other JMS brokers have similar mechanisms. -Rich On Sun, Oct 9, 2011 at 1:50 PM, Christian Schneider <ch...@die-schneider.net > wrote: > 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 > enough. > If not then a very good solution for your problem would be distributed > cache like http://memcached.org/ > > Christian > > > 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<chris@die-schneider.**net<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 >>> >>> >>> > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
