[
https://issues.apache.org/jira/browse/CXF-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang updated CXF-3097:
------------------------------
Component/s: WS-* Components
Description:
For ws-rm configuration, if acknowledgementInterval is 0(the default value),
both client and server side will use ImmediateAcknowledgement, which means try
best to not create out-of-bound SequenceAcknowledgement, this can gain higher
performance.
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.
This can cause problem for 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.
As in real scenario we generally don't know how many invocation we want to
trigger on a certain endpoint, so we actually don't know which message is last
response during runtime.
We can see this problem if we edit SequenceTest.testTwowayNonAnonymous(), add
Thread.sleep(10000);
before
verifyTwowayNonAnonymous();
to let the server side resend happen.
And observe the log we can get a clear idea about this issue.
We should be able to provide a configurable timeout for AcksPolicy, so that the
we get chance to send a out-of-bound SequenceAcknowledgement for the last
response in this case.
was:
For ws-rm configuration, if acknowledgementInterval is 0(the default value),
both client and server side will use ImmediateAcknowledgement, which means try
best to not create out-of-bound SequenceAcknowledgement, this can gain higher
performance.
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.
This can cause problem for client side of the last response message which has
SequenceAcknowledgement header, as there's no SequenceAcknowledgement for the
last response and so server side will always resend the message.
As in real scenario we generally don't know how many invocation we want to
trigger on a certain endpoint, so we don't know which message is last response
during runtime.
We can see this problem if we edit SequenceTest.testTwowayNonAnonymous(), add
Thread.sleep(10000);
before
verifyTwowayNonAnonymous();
to let the server side resend happen.
We should be able to provide a configurable timeout for AcksPolicy, so that the
we get chance to send a out-of-bound SequenceAcknowledgement for the last
response in this case.
> ws-rm ImmediateAcknowledgement doesn't work for ws-rm client side
> -----------------------------------------------------------------
>
> Key: CXF-3097
> URL: https://issues.apache.org/jira/browse/CXF-3097
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.3.0, 2.2.11
> Reporter: Freeman Fang
> Assignee: Freeman Fang
> Fix For: 2.2.12, 2.3.1, 2.4
>
>
> For ws-rm configuration, if acknowledgementInterval is 0(the default value),
> both client and server side will use ImmediateAcknowledgement, which means
> try best to not create out-of-bound SequenceAcknowledgement, this can gain
> higher performance.
> 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.
> This can cause problem for 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.
> As in real scenario we generally don't know how many invocation we want to
> trigger on a certain endpoint, so we actually don't know which message is
> last response during runtime.
> We can see this problem if we edit SequenceTest.testTwowayNonAnonymous(), add
> Thread.sleep(10000);
> before
> verifyTwowayNonAnonymous();
> to let the server side resend happen.
> And observe the log we can get a clear idea about this issue.
> We should be able to provide a configurable timeout for AcksPolicy, so that
> the we get chance to send a out-of-bound SequenceAcknowledgement for the last
> response in this case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
