----- Original Message -----
Sent: Friday, January 06, 2006 3:06
AM
Subject: [Sandesha2] Acknowledging
policy
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 the message is received by the
RMEndpoint and that means we should acknowledge.
But it seems like we can provide a
better quality reliability by not acknowledging 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).
>>Yes, but the problem is once the message
is received by the RMEndpoint it is RMEndpoints responsibility to invoke the
web service. So what we want >>is to improve the reliability of the
RMEndpoint.
>>IMHO we should not expect the initial
sender to wait till the web service gets invoked for an
acknowledgment.
>>Consider a scenario where we have 3
messages and the RMEndpoint manager in the destination receive 2 and 3 but not
1. We use INORDER >>invocation. Now we will not acknowledge for any of
the messages since we did not receive message 1. This is not correct, because
then the >>RMEndpoint manager in the client side will keep on sending
all the 3 messages again and again.
Now an interesting problem arises 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.
>>I think we should have a consistent
acknowledgement mechanism in all the cases.
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).
>>Let's try to get this working. So we have
the maximum reliability :)
Thank you,
Chamikara
