[
https://issues.apache.org/jira/browse/CXF-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14002397#comment-14002397
]
Dennis Sosnoski commented on CXF-3272:
--------------------------------------
I'll get a fix in for this. Though in looking it over now I don't see any
reason to hold WeakReferences to the messages - if the response has been
acknowledged we can drop it, and if the same request is sent in again (which
shouldn't happen, since the response would include an acknowledgement of the
request the first time it was sent) we can just use an empty SOAP message.
> 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)
