Thanks for the tips, guys. We'll have a think about it and run a few tests :)
On 10 October 2011 15:32, Rich Newcomb <rich.newc...@gmail.com> wrote: > 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 > > > > >
