Re: Questions about WS-RM behavior in CXF

[Akitoshi Yoshida <sa...@googlemail.com>]

Hi Dan,
Thank you for your reply.

I experimented with the code and I think for the current
implementation, the best solution would be to fix the issue at the
RetransmissionInterceptor's fault handling so that the exception
object removed during its fault processing.

I think it's okay to throw an exception if something goes wrong before
the retransmitter takes the responsibility. So if something goes wrong
at sequence creation, the client can handle this exception just like
if something went wrong in some prior interceptor.

But when you are using WS-RM and the call reached the place where the
retransmitter is activated, the client should be freed from the
responsibility of handling exceptions. Otherwise, there is no benefit
in using WS-RM.


So I will create a JIRA ticket for this issue. Adding the code below
in the handle method resolves this issue.

        if (isFault) {
            // remove the exception set by the PhaseInterceptorChain
so that the error does not reach the client
            // when retransmission is scheduled
            message.setContent(Exception.class, null);
            message.getExchange().put(Exception.class, null);
        }
        else {
            ...
        }

Regards, Aki

On Thu, May 27, 2010 at 9:54 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Tuesday 25 May 2010 12:42:49 pm Akitoshi Yoshida wrote:
>> Hi CXF-experts,
>>
>> Some days ago, I asked my question about the expected behavior of the
>> WS-RM client. I am confused that the network exception is passed back
>> to the client application, while the RetransmissionInterceptor on the
>> client keeps retransmitting the message. I expected that the exception
>> would be handled by one of the RM interceptors so that the client
>> would not get the network exception directly.
>
> Honestly, I have no idea what the right thing to do is here for exceptional
> conditions prior (or during) the CreateSequence.  If the client cannot create
> a sequence, there really isn't any way to EVER know if a sequence will be
> creatable and thus we could end up trying to retransmit forever.   This is
> especially of interest for the OneWays that have no other way to get any type
> of fault back.
>
> Technically, per JAX-WS spec, if there is a problem transmitting the message,
> the "greetMeOneWay()" method MUST throw and exception prior to returning so
> that the client knows that the one-way method did not succeed.   This may fall
> into the same category.   If the sequence could not be created for any reason,
> then we have no guarantee that the message would  ever be able to be
> transmitted and we should either throw an exception or block until the
> sequence can be created (which may defeat the purpose of the OneWay method).
>
> That said, from what you say, there is a bug.   If the exception is thrown, it
> shouldn't be trying to retransmit.   It needs to be one or the other.
>
> Dan
>
>
>> (my original question
>> http://mail-archives.apache.org/mod_mbox/cxf-users/201005.mbox/%3CAANLkTilh
>> JqYW-Bw5gWpZjoczq_HUsQuOMTbjDBy-e4qB@mail.gmail.com%3E)
>>
>> Looking further into the code today, I see that the exception is
>> passed back to the client because it is set both in message's content
>> and in its exchange map at the PhaseInterceptorChain's doIntercept
>> method below:
>>
>>                         message.setContent(Exception.class, ex);
>>                         boolean isOneWay = false;
>>                         if (message.getExchange() != null) {
>>                             message.getExchange().put(Exception.class, ex);
>>                             isOneWay = message.getExchange().isOneWay();
>>                         }
>>                         unwind(message);
>>
>> Later, the existence of the exception object is checked by the
>> ClientImpl class in its processResult method and if found, this throws
>> this exception to the client.
>>
>> Here I have two questions.
>>
>> 1. why does my oneway method initiated by port.greetMeOneWay method of
>> the demo sample invoke the ClientImpl that calls the processResult
>> method? Isn't the processResult method only needed for
>> request-response processing?
>>
>> 2. If the processResult method is called for oneway calls, should the
>> RetransmissionInterceptor's handleFault method remove the exception
>> object from the message and its exchange map? If this is done, the
>> exception would not be removed during the unwind method of the
>> doInterceptor method above and the original exception would not be
>> forwarded to the client application. This seems to work for me.
>>
>> I would appreciate if someone can answer my questions.
>>
>> Thanks.
>>
>> Regards, aki
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>