CXF
  1. CXF
  2. CXF-4164

Robust-InOnly processing with WS-RM must must delay updating the sequence until message delivery

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.4.7, 2.5.3
    • Fix Version/s: 2.4.7, 2.5.3, 2.6
    • Component/s: WS-* Components
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      A recently added robust-inonly mode (CXF-4096) can be used to invoke services synchronously so that the caller can distinguish a successful invocation from an unsuccessful one.

      Although this feature is implemented independently of WS-RM, it can be used with WS-RM to force the acknowledgement message to be returned only after the service invocation successfully completes.

      Unfortunately, there is a minor change required in WS-RM so that this feature will work for this use case. Namely, it must be made aware of this robust setting so that it can postpone updating the sequence until the message is delivered.

        Activity

        Aki Yoshida created issue -
        Aki Yoshida made changes -
        Field Original Value New Value
        Summary Robust-InOnly processing with WS-RM must must wait for updating the sequence until message delivery Robust-InOnly processing with WS-RM must must delay updating the sequence until message delivery
        Hide
        Dennis Sosnoski added a comment -

        This is probably the way all WS-RM processing should work, so that messages are only acknowledged once they've been delivered to the application and processed. The current code appears to allow a timing window where a crash would mean the message has been accepted and acknowledged by RM processing but is never seen by the application.

        It looks like all that needs to be done for 2.5.x+ is to remove the call to destination.acknowledge() from RMInInterceptor.processSequence() and instead call it from RMDeliveryInterceptor.handle() (before the call to processingComplete()).

        Show
        Dennis Sosnoski added a comment - This is probably the way all WS-RM processing should work, so that messages are only acknowledged once they've been delivered to the application and processed. The current code appears to allow a timing window where a crash would mean the message has been accepted and acknowledged by RM processing but is never seen by the application. It looks like all that needs to be done for 2.5.x+ is to remove the call to destination.acknowledge() from RMInInterceptor.processSequence() and instead call it from RMDeliveryInterceptor.handle() (before the call to processingComplete()).
        Hide
        Aki Yoshida added a comment -

        Hi Dennis,

        As I mentioned in my reply on dev@cxf at
        http://cxf.547215.n5.nabble.com/Re-svn-commit-r1297370-in-cxf-branches-2-5-x-fixes-rt-ws-rm-src-main-java-org-apache-cxf-ws-rm-syste-td5540174.html

        This is an option for not losing messages at Destination. For many applications, this option will be sufficient. For those which expect an asynchronous decoupling of the message transport to the service invocation, this will be insufficient and we will still need a message storage and a re-delivery logic from the storage, which is currently missing.

        So, I will be adding to this ticket an optimization change to avoid persisting the messages at Destination for the robust-mode. Currently, the messages are always persisted independently of the mode.

        regards, aki

        Show
        Aki Yoshida added a comment - Hi Dennis, As I mentioned in my reply on dev@cxf at http://cxf.547215.n5.nabble.com/Re-svn-commit-r1297370-in-cxf-branches-2-5-x-fixes-rt-ws-rm-src-main-java-org-apache-cxf-ws-rm-syste-td5540174.html This is an option for not losing messages at Destination. For many applications, this option will be sufficient. For those which expect an asynchronous decoupling of the message transport to the service invocation, this will be insufficient and we will still need a message storage and a re-delivery logic from the storage, which is currently missing. So, I will be adding to this ticket an optimization change to avoid persisting the messages at Destination for the robust-mode. Currently, the messages are always persisted independently of the mode. regards, aki
        Aki Yoshida made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Daniel Kulp made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Aki Yoshida
            Reporter:
            Aki Yoshida
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development