On 1/9/06, Aleksander Slominski <[EMAIL PROTECTED]
> wrote:
That is exactly the feature I'm talking abt. With this Sandesha2 will not ack without invoking the message even in the in-memory case. We can also make this optional so that users who need acks quickly can get them before invocation (this will be the default).
Thanx,
Chamikara
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 ...)
That is exactly the feature I'm talking abt. With this Sandesha2 will not ack without invoking the message even in the in-memory case. We can also make this optional so that users who need acks quickly can get them before invocation (this will be the default).
Thanx,
Chamikara
