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 Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Resolved at Apache
    • Affects Version/s: 2.2.6-fuse-01-00
    • Component/s: None
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      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.

        Activity

        Hide
        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
        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
        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
        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:
            Freeman(Yue) Fang
            Reporter:
            Stan Lewis
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: