Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <1917298.18811293316725616.JavaMail.jira@thor>
Date: Sat, 25 Dec 2010 17:38:45 -0500 (EST)
From: "Aki Yoshida (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Created: (CXF-3219) WS-RMs' DestinationSequence does not
 update the ack range in the RMStore
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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.