Re: [Resteasy-users] Resteasy Client does not properly handle Server exception, rendering Client inoperable

[Anthony W. <an...@wh...>]

I created a fix for this issue by modifying the error handling of the ClientInvocation.extractResult method.

See Pull Request:  https://github.com/resteasy/Resteasy/pull/397

My primary concern about catching WebApplicationException all over the place is that it seems to violate Separation of Concerns.  A user of the interface is not responsible for allocating or managing the connection, so why should it be responsible for closing it?  As a user of the interface, it may not even be clear that it is an RPC call -- that is some of the beauty of the abstraction.

Note that in my example, the error message still comes through as text/html...  But the status code is 500.  I am merely focused on not violating the underlying Apache Client state.

Please review.  Thank you,

Anthony



On Oct 17, 2013, at 2:10 PM, Bill Burke <bb...@re...> wrote:

> Unfortunately, you are responsible for cleaning up the connection 
> yourself.  You must do:
> 
> try {
> 
>    ... do something with client ...
> 
> } catch (WebApplicationException ex) {
> 
> ex.getResponse().close();
> 
> }
> 
> This is because the response may contain an entity that the user wants 
> to access.  I'm pretty sure we're not allowed to automatically close the 
> underlying Response object.
> 
> 
> On 10/17/2013 10:01 AM, Anthony Whitford wrote:
>> I discovered a particularly nasty problem using the Resteasy Client
>> Framework and have documented it in the issue tracker:
>> https://issues.jboss.org/browse/RESTEASY-963
>> 
>> In a nutshell, if a Client Proxy instance makes a call to the service
>> and the service throws an exception, the Client is now rendered
>> inoperable because the underlying connection is not adequately reset.
>> 
>> A sample project is included with the issue that demonstrates the
>> problem.  Note that there is a scenario (when a connection pool no
>> longer has a valid connection available) where the call becomes FROZEN!
>> 
>> If I had to guess on the solution, I would say that the invoke method
>> of ClientInvoker needs to catch the exception and release the underlying
>> connection in the event of an exception.
>> 
>> https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/internal/proxy/ClientInvoker.java#L104
>> 
>> I think this is similar to the issue raised by John D. Ament on the
>> 15th.  (Resteasy should automatically clean up
>> the connection, but this can not be limited to a GC event because we
>> have no control over GC events.)
>> 
>> I look forward to seeing this fixed as this is a serious stability risk.
>>  Thank you,
>> 
>> Anthony
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>> 
>> 
>> 
>> _______________________________________________
>> Resteasy-users mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users