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<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
