You are viewing a plain text version of this content. The canonical link for it is here.

Posted to sandesha-dev@ws.apache.org by Chamikara Jayalath <ch...@gmail.com> on 2006/01/06 09:06:04 UTC

[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 it seems like we can provide a better quality reliability by not
acknowleding 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).

Now an interesting problem arrises when we consider the implementation of
the above scenario. Suppose a message arrives to an RM enabled In-Only
operation. Now SandeshaOutHandler does not get called and we have to send
the ack within the in-path. How can we do something after invocation within
the in-path. Here is one way,

Currently we do in-order invocation using the InOrderInvoker thread. Within
the SandeshaInHandler we pause the messages, and the InOrderInvoker resumes
them in the correct order. If we make this thread the Invoker for all the
messages and if we move the ack sending logic into this, we can accomplish
above (basically we will pause all the incoming messages and we will send
the ack only after the Invoker thread resumes the message).

But when we consider the current implementation of the pause functionality
of Axis2 there is again a slight problem. When pause is called the incoming
thread simply returns. So we have to add the ack before pausing if the
acksTo endpoint is the anonymous URL.

Considering all of the above points I thought we can go for the policy given
below.

1. Sandesa2 will always use the Invoker thread to invoke messages. All
incoming request messages will be paused in the request path and they will
be resumed by the Invoker thread.

2. If the acksTo endpoint is anonymous Sandesha2 will send the
acknowledgement within the SandeshaInHandler (before actually invoking the
service.)

3. If the user has given an actual acksTo endpoint. Sandesha2 will make sure
that it only acknowledges messages after the invocation.


Remember that I'm only talking about the in-memory scenarios here. If the
user go for permanent storage based reliability, invocation of acked
messages will always be guaranteed (using message re-injection).

Thank you,
Chamikara

Re: [Sandesha2] Acknowledging policy

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Jaliya,

See my comments below.

On 1/8/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
>
> Hi Chamikara and All,
>
> Please see my comments below.
>
> Thanks,
>
> Jaliya
>
> ----- Original Message -----
> *From:* Chamikara Jayalath <ch...@gmail.com>
> *To:* sandesha-dev@ws.apache.org
> *Sent:* Saturday, January 07, 2006 11:56 PM
> *Subject:* Re: [Sandesha2] Acknowledging policy
>
>
>
> 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
>
>
> Your point is correct, but can we generalize this to suite all the cases?
> Say we acknowledge the only when the service gets invoked, but if the
> service takes a long time to complete then we are waiting unnecessarily for
> acknowledgements.
> It can be a option in Sandesha but it should not be the default case. Many
> people worry about the message losses than the failover so we have to
> support the common case efficiently.
>
>
OK. Then lets make this an option. If people can provide a true acksTo
endpoint and if they can bear the time that is taken for an processing the
request, then they can turn that on. We can turn it off by default.


Thanks,
Chamikara

Re: [Sandesha2] Acknowledging policy

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Jaliya,

See my comments below.

On 1/8/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
>
> Hi Chamikara and All,
>
> Please see my comments below.
>
> Thanks,
>
> Jaliya
>
> ----- Original Message -----
> *From:* Chamikara Jayalath <ch...@gmail.com>
> *To:* sandesha-dev@ws.apache.org
> *Sent:* Saturday, January 07, 2006 11:56 PM
> *Subject:* Re: [Sandesha2] Acknowledging policy
>
>
>
> 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
>
>
> Your point is correct, but can we generalize this to suite all the cases?
> Say we acknowledge the only when the service gets invoked, but if the
> service takes a long time to complete then we are waiting unnecessarily for
> acknowledgements.
> It can be a option in Sandesha but it should not be the default case. Many
> people worry about the message losses than the failover so we have to
> support the common case efficiently.
>
>
OK. Then lets make this an option. If people can provide a true acksTo
endpoint and if they can bear the time that is taken for an processing the
request, then they can turn that on. We can turn it off by default.


Thanks,
Chamikara

Re: [Sandesha2] Acknowledging policy

Posted by Jaliya Ekanayake <jn...@gmail.com>.

Hi Chamikara and All,

Please see my comments below.

Thanks,

Jaliya
----- Original Message -----
From: Chamikara Jayalath
To: sandesha-dev@ws.apache.org
Sent: Saturday, January 07, 2006 11:56 PM
Subject: Re: [Sandesha2] Acknowledging policy

Hi Jaliya, All,

See my comments below

----- Original Message -----
From: Chamikara Jayalath
To: 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.

Your point is correct, but can we generalize this to suite all the cases?
Say we acknowledge the only when the service gets invoked, but if the service takes a long time to complete then we are waiting unnecessarily for acknowledgements.
It can be a option in Sandesha but it should not be the default case. Many people worry about the message losses than the failover so we have to support the common case efficiently.

If someone needs failover recovery then he should definitely go for a better solution like persistence Sandesha. Even if we acknowledge messages when they actually handed over to the service, we cannot get the reliability as per the persistence case, so IMHO we should not worry about providing another halfway persistence option sacrificing the performance.

Now an interesting problem arises when we consider the implementation of the above scenario. Suppose a message arrives to an RM enabled In-Only operation. Now SandeshaOutHandler does not get called and we have to send the ack within the in-path. How can we do something after invocation within the in-path. Here is one way,

Currently we do in-order invocation using the InOrderInvoker thread. Within the SandeshaInHandler we pause the messages, and the InOrderInvoker resumes them in the correct order. If we make this thread the Invoker for all the messages and if we move the ack sending logic into this, we can accomplish above (basically we will pause all the incoming messages and we will send the ack only after the Invoker thread resumes the message).

But when we consider the current implementation of the pause functionality of Axis2 there is again a slight problem. When pause is called the incoming thread simply returns. So we have to add the ack before pausing if the acksTo endpoint is the anonymous URL.

Considering all of the above points I thought we can go for the policy given below.

1. Sandesa2 will always use the Invoker thread to invoke messages. All incoming request messages will be paused in the request path and they will be resumed by the Invoker thread.

2. If the acksTo endpoint is anonymous Sandesha2 will send the acknowledgement within the SandeshaInHandler (before actually invoking the service.)

3. If the user has given an actual acksTo endpoint. Sandesha2 will make sure that it only acknowledges messages after the invocation.

>>I think we should have a consistent acknowledgement mechanism in all the cases.

Agree.But I feel it is consistent enough. We can clearly say that the client can get a better quality reliability (even in the in-memory case) if he specify a true acksTo endpoint (let's document this well :-) ). I feel it is better than giving a lower quality in both cases.

I don't think we give a lower quality product. These are two different problems we try to solve. One is reliability over the wire and the failover recovery. We have solutions for both in Sandesha (once we have persistence version out)

Remember that I'm only talking about the in-memory scenarios here. If the user go for permanent storage based reliability, invocation of acked messages will always be guaranteed (using message re-injection).

>>Let's try to get this working. So we have the maximum reliability :)

It is already working. But the prob is code is dependent on Hibernate so I'm not able to commit the permanent storage pluging. I'll try to create another plugin using Apache JDO.

Let's wait till the license thingy gets solved.

Cool, +1 for JDO.

Thanx,
Chamikara

Re: [Sandesha2] Acknowledging policy

Posted by Aleksander Slominski <as...@cs.indiana.edu>.

Chamikara Jayalath wrote:

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

Re: [Sandesha2] Acknowledging policy

Posted by Aleksander Slominski <as...@cs.indiana.edu>.

Chamikara Jayalath wrote:

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

Re: [Sandesha2] Acknowledging policy

Posted by Aleksander Slominski <as...@cs.indiana.edu>.

more on this subject in more generic context:
http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0064.html

best,

alek

---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: [Sandesha2] Acknowledging policy

Posted by Aleksander Slominski <as...@cs.indiana.edu>.

more on this subject in more generic context:
http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0064.html

best,

alek

---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: [Sandesha2] Acknowledging policy

Posted by Chamikara Jayalath <ch...@gmail.com>.

On 1/9/06, Aleksander Slominski <as...@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>> wrote:
> >
> >     hi,
> >
> >     my comments below.
> >
> >     Chamikara Jayalath wrote:
> >
> >>             ----- Original Message -----
> >>             *From:* Chamikara Jayalath <ma...@gmail.com>
> >>             *To:* 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. 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

Re: [Sandesha2] Acknowledging policy

Posted by Chamikara Jayalath <ch...@gmail.com>.

On 1/9/06, Aleksander Slominski <as...@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>> wrote:
> >
> >     hi,
> >
> >     my comments below.
> >
> >     Chamikara Jayalath wrote:
> >
> >>             ----- Original Message -----
> >>             *From:* Chamikara Jayalath <ma...@gmail.com>
> >>             *To:* 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. 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

Re: [Sandesha2] Acknowledging policy

Posted by Aleksander Slominski <as...@cs.indiana.edu>.

Chamikara Jayalath wrote:

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

best,

alek

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


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: [Sandesha2] Acknowledging policy

Posted by Aleksander Slominski <as...@cs.indiana.edu>.

Chamikara Jayalath wrote:

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

best,

alek

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


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: [Sandesha2] Acknowledging policy

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Alec,

See my comments below.

On 1/9/06, Aleksander Slominski <as...@cs.indiana.edu> wrote:
>
> hi,
>
> my comments below.
>
> Chamikara Jayalath wrote:
>
>   ----- Original Message -----
> >  *From:* Chamikara Jayalath <ch...@gmail.com>
> > *To:* 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.




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


Thanks,
Chamikara

Re: [Sandesha2] Acknowledging policy

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Alec,

See my comments below.

On 1/9/06, Aleksander Slominski <as...@cs.indiana.edu> wrote:
>
> hi,
>
> my comments below.
>
> Chamikara Jayalath wrote:
>
>   ----- Original Message -----
> >  *From:* Chamikara Jayalath <ch...@gmail.com>
> > *To:* 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.




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


Thanks,
Chamikara

Re: [Sandesha2] Acknowledging policy

Posted by Aleksander Slominski <as...@cs.indiana.edu>.

hi,

my comments below.

Chamikara Jayalath wrote:

>         ----- Original Message -----
>         *From:* Chamikara Jayalath <ma...@gmail.com>
>         *To:* sandesha-dev@ws.apache.org
>         <ma...@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?

i think that in case of in-memory storage not much can be done for 
reliability but ask user to buy UPS :)

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

thanks,

alek

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

Re: [Sandesha2] Acknowledging policy

Posted by Aleksander Slominski <as...@cs.indiana.edu>.

hi,

my comments below.

Chamikara Jayalath wrote:

>         ----- Original Message -----
>         *From:* Chamikara Jayalath <ma...@gmail.com>
>         *To:* sandesha-dev@ws.apache.org
>         <ma...@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?

i think that in case of in-memory storage not much can be done for 
reliability but ask user to buy UPS :)

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

thanks,

alek

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