[
https://issues.apache.org/jira/browse/CXF-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14002533#comment-14002533
]
Aki Yoshida commented on CXF-3272:
----------------------------------
Hi Dennis,
For the oneway case, most clients expect to receive an ack message with the
current ack ranges. If you can get this oneway handling working, that would be
great.
Regarding the request-response case, the response message is queued and its
delivery is handled independently of any subsequent retransmission of the
original request, right? In that case, I think not including (or triggering)
the response as you suggest seems to be the correct behavior.
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)
