Hi All,

It seems like we need to do some adjustments to our acknowledging policy.

Currently acknowledging incoming application messages is done by the SandeshaInHandler. So acknowledging happens before the message is actually delivered to the service.

But it seems like we can provide a better quality reliability by not acknowleding till we actually invoke the service. This way we can guarantee the delivering of the message to the service even in the in-memory case. (I.e. if the client receive an ack he can be sure that the service got actually invoked).

Now an interesting problem arrises when we consider the implementation of the above scenario. Suppose a message arrives to an RM enabled In-Only operation. Now SandeshaOutHandler does not get called and we have to send the ack within the in-path. How can we do something after invocation within the in-path. Here is one way,

Currently we do in-order invocation using the InOrderInvoker thread. Within the SandeshaInHandler we pause the messages, and the InOrderInvoker resumes them in the correct order. If we make this thread the Invoker for all the messages and if we move the ack sending logic into this, we can accomplish above (basically we will pause all the incoming messages and we will send the ack only after the Invoker thread resumes the message).

But when we consider the current implementation of the pause functionality of Axis2 there is again a slight problem. When pause is called the incoming thread simply returns. So we have to add the ack before pausing if the acksTo endpoint is the anonymous URL.

Considering all of the above points I thought we can go for the policy given below.

1. Sandesa2 will always use the Invoker thread to invoke messages. All incoming request messages will be paused in the request path and they will be resumed by the Invoker thread.

2. If the acksTo endpoint is anonymous Sandesha2 will send the acknowledgement within the SandeshaInHandler (before actually invoking the service.)

3. If the user has given an actual acksTo endpoint. Sandesha2 will make sure that it only acknowledges messages after the invocation.


Remember that I'm only talking about the in-memory scenarios here. If the user go for permanent storage based reliability, invocation of acked messages will always be guaranteed (using message re-injection).

Thank you,
Chamikara

Reply via email to