cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject Re: An option for performing oneway calls synchronously to be able to handle errors consistently
Date Mon, 06 Feb 2012 16:50:05 GMT
2012/2/6 Daniel Kulp <dkulp@apache.org>:
> On Monday, February 06, 2012 11:39:24 AM Aki Yoshida wrote:
>> Hi,
>> I would like to have an option to be able to invoke oneway calls
>> synchronously so that the caller will get an HTTP 202 when no error
>> occurs at the provider side but it will get an HTTP 500 SOAP fault
>> when some error occurs. There seems to be no option available to
>> enforce this behavior.
>
> Yea, as it's against spec and likely wouldn't be interopable with other
> stacks.....    One thing that may need to be checked is how the various stacks
> would deal with a soap:fault on a one-way.  If a stack isn't expecting it, not
> sure what they'd do.

I think there is a grey area in the interpretation of the spec.
Logically, in the application's message exchange level, we can all
agree that there is no fault returned to the caller. But there are all
kinds of error situations during the oneway call. Some errors are
already generating an HTTP 500 response and the CXF oneway client
already handles it as an exception just as handling other kind of
errors such as HTTP errors or IO errors. In such cases, the client
sees javax.xml.ws.WebServiceException. I think all clients expect a
successful oneway call to result in an HTTP 202 or 200 and if it
receives something else, they can treat it as some runtime error. So,
I think we are not breaking them.


>
>> Currently, errors occurring at the provider side for oneway calls lead
>> to sometimes to an HTTP 500 SOAP fault and sometimes to no error but
>> simply an HTTP 202 response depending on where exactly the error
>> occurs. Providing this option to invoke a oneway call synchronously
>> and  returning an HTTP 500 fault to the caller upon some error will
>> allow the caller to handle various invocation errors more
>> consistently.
>>
>> I would like to achieve this synchronous behavior without forcing the
>> service definition to be rewritten into a request-response one. In
>> that way, existing plain oneway services can be invoked in a more
>> controlled environment. We can look at this as robust oneway (or
>> robust inOnly).
>
> Yep.   The WSDL2 spec really did get the extra exchange patterns to be a lot
> better.
>
>> Another benefit of providing this option will be a more efficient
>> handling of large data. If the call is handled synchronously, the
>> input data does not need to be sucked in and cached internally before
>> being needed.
>>
>> I tried out adding this option by modifying OneWayProcessorInterceptor
>> slightly. Basically, when this option is enabled, it invokes the rest
>> of this oneway call and if there is an error, it switches the
>> exchange's oneway flag to false and calls the fault observer.
>
> The OneWayProcessorInterceptor already has the USE_ORIGINAL_THREAD which I
> think covers the first part, right?      The other part of this would just
> occur in the handleFault method, right?
>

Yes. The USE_ORIGINAL_THREAD covers the first part and it is also fine
from the JMS perspective.
But from the HTTP perspective, it is not useful as it preemptively
returns an HTTP 202 response prior to invoking the service.

>
>> Unless someone objects to adding this option this way or has a better
>> idea of achieving this result, I would like to put this change up in
>> the code.
>>
>> Let me know how you think.
>
> No objections from my side.   Its a good start for one of the additional WSDL2
> exchange patters, not that I really expect us to ever go down the wsdl2 route.
> :-)

I think adding this runtime option is a simple thing and will be
useful in various practical scenarios.

>
> Actually, what I'd even suggest is to add an @RobustInOnly annotation that
> would set the property on the BindingOperationInfo.

That would be possible. But that means you want to statically
differentiate the service method to be either non-robust and robust,
as if we are going the wsdl2 route?

I thought it would be beneficial to be able to set this option at the
published endpoint by using some message contextual property.

Regards, aki
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Mime
View raw message