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.3.1, 2.2.12
Reporter: Aki Yoshida
Fix For: 2.3.2
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.
