cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <j...@apache.org>
Subject [jira] Created: (CXF-3219) WS-RMs' DestinationSequence does not update the ack range in the RMStore
Date Sat, 25 Dec 2010 22:38:45 GMT
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.


Mime
View raw message