You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2010/10/29 11:08:19 UTC

[jira] Resolved: (CXF-3097) ws-rm ImmediateAcknowledgement doesn't work for ws-rm client side

     [ https://issues.apache.org/jira/browse/CXF-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Freeman Fang resolved CXF-3097.
-------------------------------

    Resolution: Fixed

commit fix

http://svn.apache.org/viewvc?rev=1028170&view=rev for trunk
http://svn.apache.org/viewvc?rev=1028647&view=rev for 2.3 branch
http://svn.apache.org/viewvc?rev=1028651&view=rev for 2.2 branch

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