Re: [xmlblaster] PtP and ACK

[Michele Laghi <laghi at swissinfo.org>]

Salut Nicolas,

Nicolas Rod wrote:
> 
> Hi all,
> 
> I am very new to xmlBlaster, and have a few questions regarding our needs.
> 
> We are considering using xmlBlaster in a project which would include one
> publisher and many receivers. We would need to be sure that every
> receiver gets all messages once, and only once. We should also be sure
> that every receiver was able to treat the message correctly.
> 
> After a few tests, I could run an example with one publisher and two
> receivers in a way that seems to be close to what we are looking for,
> but a few questions remain.
> 
> This test runs in PtP mode, with clients having a pubSessionId. The
> publisher sends every messages to every receiver. If xmlBlaster is down,
> messages are queued on the publisher. If a client is down, messages are
> queued on xmlBlaster. Then when the client connects, it gets the queued
> messages. This approach means that the publisher has to know every
> receivers in order to send the messages to each of them. First question:
> is PtP with pubSessionId the good way to be sure that every message in
> received once and only once by a client ?

Not exactly, I would additionally choose failsafe mode, persistent
messages and persistent sessions&subscriptions. The PtP is not really
needed, you could also work with pub/sub and acheave the same goal with
the benefit of not needing to know the receiver.

> 
> Next, what happens if a receiver can't treat the message ? Or if the
> receiver gets down before having done its job with the message ? In my
> test, every receiver sends an ACK message back to the publisher. But I'm
> not sure what to do with this ACK message. Is there anything already
> built in xmlBlaster which can be configured in case an ACK message isn't
> sent back to a publisher ? Such as trying to send it again or anything ?
> Or does this logic has to be fully implemented in the publisher itself ?
> 
It is implemented the following way:

If the server does not get the ACK from the client, the message held in
the queue and will be sent again.

If the server becomes a communication exception the message is held in
queue and sent again.

If the client throws an exception in the update method, the behaviour
depends on the kind of exception thrown. For an XmlBlasterException with
error code ErrorCode.USER_UPDATE_HOLDBACK the message is kept in the
queue (callback queue) and the dispatcher is stopped (to avoid looping).
You have then to reactivate the dispatcher and the message is sent again.

For all other exceptions the message is deleted from the queue and
handled as a deadMessage.

> Finally, during these first tests, I tried to shutdown a receiver, and
> then send a message to it. When I restart this receiver, it connects to
> xmlBlaster with the same previous pubSessionId, and thus receives the
> messages which where queued on xmlBlaster. Though, I get a problem
> sometimes when trying to send back ACK messages. The 'connect' method of
> the I_XmlBlasterAccess is called with a new I_Callback() object
> containing an 'update' method which tries to send an ACK message.
> Sometimes sending an ACK message raises an 'user.notConnected' error.
> What is not clear for me is that the receiver tries to send an ACK
> message after having received a message. Therefore, I would have thought
> the receiver was already connected. Why this error ? There must be a
> concept I don't understand here.
> 
My guess is the following:
you are in the update method when shutting down. Shutting down
(disconnecting) is happening faster than your update method. When your
update method is finished and sends back the acknowledge the client has
already been disconnected and its resources on the serverside have
already been cleaned up.

Cheers
Michele


> Thanks for your help !
> Nicolas
> 
> 
> -- 
> *Nicolas ROD*
> UniGe - NTIC
> Uni Dufour, bureau 360A