cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <>
Subject [jira] [Assigned] (CXF-3219) WS-RMs' DestinationSequence does not update the ack range in the RMStore
Date Fri, 29 Apr 2011 22:33:03 GMT


Aki Yoshida reassigned CXF-3219:

    Assignee: Aki Yoshida

> WS-RMs' DestinationSequence does not update the ack range in the RMStore
> ------------------------------------------------------------------------
>                 Key: CXF-3219
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 2.2.12, 2.3.1
>            Reporter: Aki Yoshida
>            Assignee: Aki Yoshida
>         Attachments: rt-ws-rm-2.3.x-fixes-diff.txt
> This problem is described in my mail to the cxf-user list.
> 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.
For more information on JIRA, see:

View raw message