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