[#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

FUSE Services Framework

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

Created: 06/Jul/10 01:17 PM Updated: 24/Nov/10 04:44 AM

Component/s:

None

Affects Version/s:

2.2.6-fuse-01-00

Fix Version/s:

2.3.0-fuse-00-00, 2.2.11-fuse-00-00

File Attachments:

test-case.tar.gz (45 kB)

External Issue URL:

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

Description

« Hide

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.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Stan Lewis added a comment - 06/Jul/10 01:18 PM

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.

[ Permlink | « Hide ]

Freeman Fang added a comment - 29/Oct/10 08:47 AM

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