cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Sosnoski (Assigned) (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (CXF-3272) WS-RM returns Fault for duplicate message received, should probably return acknowledgement instead
Date Fri, 24 Feb 2012 22:31:51 GMT

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

Dennis Sosnoski reassigned CXF-3272:
------------------------------------

    Assignee: Dennis Sosnoski
    
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message