[ 
https://issues.apache.org/jira/browse/CXF-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Sosnoski resolved CXF-3272.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 3.0.1

Fixed by http://git-wip-us.apache.org/repos/asf/cxf/commit/c613aa49

> 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
>             Fix For: 3.0.1
>
>
> 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)

Reply via email to