ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: [Sandesha2] Acknowledging policy
Date Tue, 10 Jan 2006 09:41:42 GMT
Chamikara Jayalath wrote:

>
>
> On 1/9/06, *Aleksander Slominski* <aslom@cs.indiana.edu 
> <mailto:aslom@cs.indiana.edu>> wrote:
>
>     Chamikara Jayalath wrote:
>
>     > Hi Alec,
>     >
>     > See my comments below.
>     >
>     > On 1/9/06, *Aleksander Slominski* < aslom@cs.indiana.edu
>     <mailto:aslom@cs.indiana.edu>
>     > <mailto: aslom@cs.indiana.edu <mailto:aslom@cs.indiana.edu>>>
wrote:
>     >
>     >     hi,
>     >
>     >     my comments below.
>     >
>     >     Chamikara Jayalath wrote:
>     >
>     >>             ----- Original Message -----
>     >>             *From:* Chamikara Jayalath
>     <mailto:chamikaramj@gmail.com <mailto:chamikaramj@gmail.com>>
>     >>             *To:* sandesha-dev@ws.apache.org
>     <mailto:sandesha-dev@ws.apache.org>
>     >>             <mailto: sandesha-dev@ws.apache.org
>     <mailto:sandesha-dev@ws.apache.org>>
>     >>             *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.

will it wait until invocation is finished? what if the service invoked 
spins another thread to do actual computation/message processing 
(typical for receiving one way messages when a service wants to return 
fast to allow servlet container to close HTTP connection thread)? it 
looks to me that this can only made reliable by combining WS-RM with 
transactions (so no side effects and aborted invocations are rolled back 
and be retried when server recovered by re-processing rolled back 
message queues) ...

> We can also make this optional so that users who need acks quickly can 
> get them before invocation (this will be the default).

IMHO in-memory storage is not good choice for WS-RM impl and trying to 
improve it may not be that useful ...

best,

alek

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


Mime
View raw message