Re: [wsrm] Detailed proposal to allow Batching of Acks and RM faults using ResponseReply pattern.

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

Tom Rutt wrote:

> Lines 1019 thru 1024 currently state the following:
>
> “
> - *Response *: An Acknowledgment message (or Fault message) MUST be sent
> back
> directly in the response to the Reliable Message. This pattern is not
> applicable for one-way application level MEP. The acknowledgment
> message that can be sent back in the response is for the message in the
> request only. Acknowledgment message for the former request
> MUST NOT be sent back.
> “
>
> To allow the receiving RMP to return acks or falts for former requests,
> the last two sentences are too strong:

 I believe I mentioned this many times so far, there is no mechanism to
 to identify a Sender in a standard way in either the Response or Poll case.

>
>
> Replace the last two sentence in the above quoted text with the following:
> “
> Acknolwedgements or RM fault indications for former requests MAY also be
> included in the response,
> if they were unable to be returned in their own responses.
>

 -1.

 In R-R case, when the Sender doesn't receive a response, they will
 generally do a retry. So I don't see a need to support this use case.

>
> NOTE: In cases where the underlying transport connection is not
> available to return an Acknolwedgement or RM fault, a Receiving RMP MAY
> include that Acknowledgement or RM fault with the response to a future
> reliable message request with the same GroupID.
> “
>

 -1.

 As I mentioned in one of the con. call, 2 different nodes can share the
 same groupId and be part of the same group. In such case, there is no
 guarantee that subsequent "acks" will go back to the original and destined
 Sender.


>
> --
> ----------------------------------------------------
> Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.