You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jim Talbut <jt...@spudsoft.co.uk> on 2015/06/27 11:34:45 UTC

HTTP status code and streamed responses

Hi,

I have a CXF JAX-RS resource that returns a PipedInputStream as the entity.
The matching PipedOutputStream is filled from a Spring JDBC Template 
method in another thread.

If an error occurs during the filling of the PipedOutputStream is there 
any way that I can get that error transferred to the Response object?
I don't really care what form the error takes, as long as the client 
knows that the output they have received is faulty.

I can't see any way to do this, and the alternative involves buffering a 
large amount of data.

At the moment I can't even catch errors in the running of the SQL, but 
if I replace the JDBC Template with raw JDBC calls and just put the 
handling of the ResultSet in the other thread I can at least catch the 
majority of errors.

Thanks for any suggestions.

Jim

Re: HTTP status code and streamed responses

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Jim

I guess after the code has written some data out then the IO error can 
not be properly reported, I guess I'd try and make sure the the data are 
written in self-contained chunks. Suppose you write the XML, so first write
<Response>

then a ready element,

<a>value</a>

and now if the IO occurs then may may
<failure>value</failure>
</Response>

As a side note, you can probably work with StreamingOutput, CXF also 
ships a helper StreamingResponse

Cheers, Sergey

On 27/06/15 10:34, Jim Talbut wrote:
> Hi,
>
> I have a CXF JAX-RS resource that returns a PipedInputStream as the entity.
> The matching PipedOutputStream is filled from a Spring JDBC Template
> method in another thread.
>
> If an error occurs during the filling of the PipedOutputStream is there
> any way that I can get that error transferred to the Response object?
> I don't really care what form the error takes, as long as the client
> knows that the output they have received is faulty.
>
> I can't see any way to do this, and the alternative involves buffering a
> large amount of data.
>
> At the moment I can't even catch errors in the running of the SQL, but
> if I replace the JDBC Template with raw JDBC calls and just put the
> handling of the ResultSet in the other thread I can at least catch the
> majority of errors.
>
> Thanks for any suggestions.
>
> Jim