cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject An option for performing oneway calls synchronously to be able to handle errors consistently
Date Mon, 06 Feb 2012 10:39:24 GMT
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.

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

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

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.

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.

Regards, aki

View raw message