[jira] [Commented] (CXF-3272) WS-RM returns Fault for duplicate message received, should probably return acknowledgement instead

["Aki Yoshida (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14001685#comment-14001685 ] 

Aki Yoshida commented on CXF-3272:
----------------------------------

Hi Dennis,
do you have an update to this item?
thanks.
regards, aki


> WS-RM returns Fault for duplicate message received, should probably return acknowledgement instead
> --------------------------------------------------------------------------------------------------
>
>                 Key: CXF-3272
>                 URL: https://issues.apache.org/jira/browse/CXF-3272
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 2.3.2
>            Reporter: Dennis Sosnoski
>            Assignee: Dennis Sosnoski
>            Priority: Minor
>
> The WS-RM Destination code currently throws an exception when a duplicate message is received if using AtMostOnce or ExactlyOnce delivery assurances. This gets turned into a Fault which means nothing to the RM Source, and may interfere with the proper operation of other WS-RM implementations.
> A better way to handle this is to return an HTTP 200 OK status (or equivalent for other transports) along with a SequenceAcknowledgement, so that the RM Source gets back information to help it in recovery.
> For one-way scenarios this can just be returned directly. For two-way scenarios it should be returned along with a copy of the application response to the original message (at least if an Offer was included in the original CreateSequence and accepted by the RM Destination, meaning RM is operating in both directions of message flow - see the Replay model implemented by Metro, along with at least some versions of .Net and Axis2/Sandesha2: http://wso2.org/library/2792).
> Metro's handling is interesting. If RM is operating in the response direction they naturally hold a copy of each response message until acknowledged, but then even after the message has been acknowledged they use a WeakReference to keep it available until it is reclaimed by GC. If RM is *not* operating in the response direction they still appear to keep the response available with a WeakReference, allowing it to be resent in response to a duplicate message. That seems like a good approach.
> If the response message is not available, is there any reason not to use an HTTP 200 response and send back a SOAP message with only the SequenceAcknowledgement?



--
This message was sent by Atlassian JIRA
(v6.2#6252)