ws-sandesha-dev mailing list archives

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

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 :-)

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..


View raw message