ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chamikara Jayalath <>
Subject [Sandesha2] Acknowledging policy
Date Fri, 06 Jan 2006 08:06:04 GMT
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

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

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,

View raw message