[
https://issues.apache.org/jira/browse/CXF-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-3219:
-----------------------------
Attachment: rt-ws-rm-2.3.x-fixes-diff.txt
svn diff for codeline 2.3.x-fixes
Affected files
2.3.x-fixes/rt/ws/rm/src/main/java/org/apache/cxf/ws/rm/Destination.java
2.3.x-fixes/rt/ws/rm/src/test/java/org/apache/cxf/ws/rm/DestinationTest.java
> 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
> Fix For: 2.3.2
>
> 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.
-
You can reply to this email to add a comment to the issue online.
