ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: [Sandesha2] Acknowledging policy
Date Mon, 09 Jan 2006 15:20:50 GMT
Chamikara Jayalath wrote:

> Hi Alec,
> See my comments below.
> On 1/9/06, *Aleksander Slominski* < 
> <>> wrote:
>     hi,
>     my comments below.
>     Chamikara Jayalath wrote:
>>             ----- Original Message -----
>>             *From:* Chamikara Jayalath <>
>>             *To:*
>>             <>
>>             *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 ...)



The best way to predict the future is to invent it - Alan Kay

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message