[jira] [Resolved] (CXF-3219) WS-RMs' DestinationSequence does not update the ack range in the RMStore

["Aki Yoshida (JIRA)" <ji...@apache.org>]

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

Aki Yoshida resolved CXF-3219.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.4.1

The described issue has been resolved with this patch. Thus, I am closing this issue ticket.

It is noted that some future changes is expected to be made in WS-RM and they will be tracked in other tickets.

> WS-RMs' DestinationSequence does not update the ack range in the RMStore
> ------------------------------------------------------------------------
>
>                 Key: CXF-3219
>                 URL: https://issues.apache.org/jira/browse/CXF-3219
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 2.2.12, 2.3.1
>            Reporter: Aki Yoshida
>            Assignee: Aki Yoshida
>             Fix For: 2.4.1
>
>         Attachments: rt-ws-rm-2.3.x-fixes-diff.txt
>
>
> This problem is described in my mail to the cxf-user list.
> http://cxf.547215.n5.nabble.com/WS-RMs-DestinationSequence-does-not-update-the-ack-range-stored-in-the-RMStore-td3315278.html
> In short, the acknowledged range information of the destination sequence is not updated in the RMTxStore for the inbound messages. So, when you stop and restart the server and the server retrieves the desctination sequences from the RMStore, the acknowledged range information is not retrieved. Consequently, the server will return the next acknowledgement with its range starting from the current messag number and not including the message numbers that have been acknowledged prior to the server restart.
> As I mentioned in the above mail, I think the Destination's acknowledge method should be modified so that the destination sequence is udpated in the storage. 
> In the attached file, I modified the Destination class's acknowledge method so that the acknowledgement sequence gets updated in the storage. I also modified the mocking part of the DestinationTest class to accommodate this change.
> As commented in the modified code, the call to the storage to update the acknowleged range requires the content of the message. Unfortunately, for the inbound processing, StaxInInterceptor has consumed the InputStream object and placed instead the XMLStreamReader in the message. But this stream reader is consumed by several interceptors and the entire content is not available at RMInInterceptor.
> If the LoggingInInterceptor is engaged, this interceptor leaves the resettable InputStream in the message. In this case, we can get the content by reading this input stream again. If this interceptor is not engaged, we cannot get the message content and we fall back to use an empty content to just update the acknowledgement range information.
> So the modified code is a workaround solution. I think a permanent solution might use another interceptor placed in front of StaxInInterceptor to store the message content. In that case, we can simply get the message content at the acknowledge method at RMInInterceptor.
> Please let me know how you think.
> Thanks.
> Regards, Aki

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira