[
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
