cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-3097) ws-rm ImmediateAcknowledgement doesn't work for ws-rm client side
Date Wed, 27 Oct 2010 13:34:19 GMT

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


Mime
View raw message