Uploaded image for project: 'FUSE Services Framework'
  1. FUSE Services Framework
  2. SF-258

WS-RM + WS-Security enabled via policies in the WSDL causes the server to send the response to the wrong endpoint on the client

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Resolved at Apache
    • Affects Version/s: 2.2.6-fuse-01-00
    • Component/s: None
    • Labels:
      None

      Description

      If you configure WS-RM and WS-Security in the WSDL the server appears to combine the WS-RM sequence acknowledgement and response from the service into the same message and send it to the client's decoupled endpoint. As the client is only expecting to receive sequence acknowledgement messages on the decoupled endpoint not the result of the service invocation it can't correlate the response properly, and so retries sending the invocation to the server.

      To run the test case just do:

      mvn clean install

      then do:

      mvn -Pserver in one terminal and mvn -Pclient in another terminal.

        Gliffy Diagrams

          Activity

          Hide
          stlewis Stan Lewis added a comment -

          Also note this appears to work fine if you explicitly configure a bus to combine ws-security and ws-rm, it's just when you try to configure this in the WSDL you run into this problem.

          Show
          stlewis Stan Lewis added a comment - Also note this appears to work fine if you explicitly configure a bus to combine ws-security and ws-rm, it's just when you try to configure this in the WSDL you run into this problem.
          Hide
          ffang Freeman(Yue) Fang added a comment -

          Hi Stan,

          In this testcase, as you didn't specify acknowledgementInterval in wsdl ws-rm policy configuration, so will use default value 0 for acknowledgementInterval, which means both client and server side will use ImmediateAcknowledgement, trying best effort to not create out-of-bind SequenceAcknowledgement, this can gain higher performance.

          The expected behavior in this case is that
          For server side, the behavior is put SequenceAcknowledgement header to the response message, for client side, the behavior is put SequenceAcknowledgement header to next invocation request message in the rm sequence.

          So what you see here "combine the WS-RM sequence acknowledgement and response from the service into the same message and send it to the client's decoupled endpoint" is expected behavior for server side, it leverage the response message to piggyback the SequenceAcknowledgement, which avoid creating another out-of-bind SequenceAcknowledgement, so get higher performance.

          The problem is actually from the client side when receive last response message which has SequenceAcknowledgement header, client will never ack the last response because there's no next invocation request which can piggyback the SequenceAcknowledgement header, and so server side will always resend the message.

          I created CXF-3097[1] to track this issue

          [1]https://issues.apache.org/jira/browse/CXF-3097

          Best Regards
          Freeman

          Show
          ffang Freeman(Yue) Fang added a comment - Hi Stan, In this testcase, as you didn't specify acknowledgementInterval in wsdl ws-rm policy configuration, so will use default value 0 for acknowledgementInterval, which means both client and server side will use ImmediateAcknowledgement, trying best effort to not create out-of-bind SequenceAcknowledgement, this can gain higher performance. The expected behavior in this case is that For server side, the behavior is put SequenceAcknowledgement header to the response message, for client side, the behavior is put SequenceAcknowledgement header to next invocation request message in the rm sequence. So what you see here "combine the WS-RM sequence acknowledgement and response from the service into the same message and send it to the client's decoupled endpoint" is expected behavior for server side, it leverage the response message to piggyback the SequenceAcknowledgement, which avoid creating another out-of-bind SequenceAcknowledgement, so get higher performance. The problem is actually from the client side when receive last response message which has SequenceAcknowledgement header, client will never ack the last response because there's no next invocation request which can piggyback the SequenceAcknowledgement header, and so server side will always resend the message. I created CXF-3097 [1] to track this issue [1] https://issues.apache.org/jira/browse/CXF-3097 Best Regards Freeman

            People

            • Assignee:
              ffang Freeman(Yue) Fang
              Reporter:
              stlewis Stan Lewis
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: