Chamikara Jayalath wrote:
Hi Alec,
See my comments below.
On 1/9/06, *Aleksander Slominski* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
hi,
my comments below.
Chamikara Jayalath wrote:
----- Original Message -----
*From:* Chamikara Jayalath <mailto:[EMAIL PROTECTED]>
*To:* [email protected]
<mailto:[email protected]>
*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.
yes, But if the server sends the messages and fail before he
actually invoke the service, the client will proceed believing
that the service got actually invoked. It is not important
weather the message got lost in the wire, or it got lost within
the server, the result is the same (the service did not get
invoked). So the result is equal to acknowledging a message the
server did not receive.
But performance wise what you say is very correct. If the server
consume a long time to invoke the service, the client will also
have to wait a long time for an acknowledgement.
i am not sure but it looks to me that those are two different
levels of reliability: reliable *message* delivery and reliable
*service invocation*. the former is what i though WS-RM is for and
the latter is not supported in WS-RM unless some special QoS
(Policy?) is used?
What I was thinking abt was the usability. Most of the time the
client may be unaware weather the service has implemented persistent
reliability or not. Also at times they may want to make sure that the
service actually got invoked before proceeding.Since we are able to
provide that, why not add the feature.
AFAICT it will make Sandesha work in different ways from other WS-RM
implementations as it is an extension.
moreover in-most case this feature ("reliable invocation") is better
supported (and more interoperable) by having a service sending a
reliably response message (with "OK" or SOAP:Fault) ...
i think that in case of in-memory storage not much can be done for
reliability but ask user to buy UPS :)
Ya, that solves the prob. Bit costly though :-)
UPSes are cheap and without them server will not be very reliable anyway
if it keeps all data in memory - what if it needs to be rebooted ...
IMHO the in-memory storage should be not a default in Sandesha2 as
it does not meet requirements of WS-RM instead some persistent
storage should be a default one - maybe just using text files to
store message (as even embedded RDBMS may be overkill for simple
installations)?
You have a point. But there may be many users who need an hi
performing in-memory case. Those who need persistence (RDBMS or file
based) can do it by a single property change..
there is clearly a trade-off between reliability and performance -
however i am not sure if in-memory storage is good enough to call it
"reliable"? what should happen when there are many ack-ed but not yet
processed messages (for example with out-of-order messages) and server
goes down? those messages will be essentially lost when server (or
client) that is using in-memory storage crashed and is restarted (for
perfect reliability TX are needed to be able to rollback in-progress
unfinished invocations ...)
best,
alek
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
