[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] subscribe id on update : new your opinion ...
Cyrille Giquello wrote:
To know if I've well understand XmlBlaster subcribe paradigm, can you
correct me if I'm wrong.
In an application, differents classes has to subscribe to topics. Each
class subscribe to a different topic than other class.
So, when classes subscribing, I store the 'subscribe id' to use it in
the update() method.
In the update() method I take the 'subscribe id' of the incoing
message and then dispatch that message to classes whish have subscibed
with that 'subscribe id'.
Is that the right way ? Am I wrong ? Is there another way ?
Yes, this is a good way.
But take care:
Sometimes the update() may arrive before the subscribe() returns and
in this case you don't know what to do with the callback message as
you haven't got the subscriptionId from your subscribe yet.
Now you can do for example:
o Block the update thread until the subscriptionId is known
(usually by a simple synchronize which blocks incoming messages
during a subscription)
o Disable the callback dispatcher until you setup is ready
(by an administrative command like "client/joe/2/?dispatcherActive=false"
and later to "true" again)
o Take control on the subscriptionId on client side, generate one and
pass it to the server with subscribeQos.setSubscriptionId("XXXX")
Thank you very much for your futur comments.