Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-3219

WS-RMs' DestinationSequence does not update the ack range in the RMStore

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.2.12, 2.3.1
    • 2.4.1
    • WS-* Components
    • None
    • Moderate

    Description

      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

      Attachments

        1. rt-ws-rm-2.3.x-fixes-diff.txt
          4 kB
          Akitoshi Yoshida

        Activity

          People

            ay Akitoshi Yoshida
            ay Akitoshi Yoshida
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: