Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Catching java.io.IOException on the server side 
Hi,

On Wed, Jul 23, 2014 at 5:34 PM, harald <sunnyday@xxxxxxxxxxx> wrote:
> Hello list,
>
> I hope somebody can point me in the right direction with the following. I already asked the Apache CXF user list (http://cxf.547215.n5.nabble.com/Catching-java-io-IOException-on-the-server-side-td5745530.html) but the few recommendations did not work.
>
>>>> copied from the post >>>
>
> Think of a simple restful webservice which just echos the data - for sure the real WS is much more complex running on ServiceMix (4.5.3 with CXF 2.6.9). The answer is delayed by 15 seconds to simulate processing time. The test client calling the WS has a requestTimeout of 10 seconds. As expected the client drops the connection and throws an exception. On the server side the process waits until the 15 seconds are over and tries to send the data back to the client - which is not longer listening. As expected the server throws an IOException (connection reset by peer).
>
> The problem is that I want to catch this exception and forward the not delivered answer to a JMS queue.
> <<< copied from the post <<<
>
> I failed to get this managed with Apache CXF and I failed with Apache Camel.
>
> Based on the stack trace I think CXF and Camel are already done and the IOException has to handled by Jetty.
>
>
> 16:17:23,333 | DEBUG | /rs/Echo/process | Server                           | 268 - org.eclipse.jetty.util - 7.5.4.v20111024 | RESPONSE /cxf/rs/Echo/process  200
> 16:17:23,333 | DEBUG | qtp1008596480-32 | ChannelEndPoint                  | 268 - org.eclipse.jetty.util - 7.5.4.v20111024 |
> java.io.IOException: Connection reset by peer
>         at sun.nio.ch.FileDispatcherImpl.read0(Native Method)[:1.7.0_55]
>         at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)[:1.7.0_55]
>         at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)[:1.7.0_55]
>         at sun.nio.ch.IOUtil.read(IOUtil.java:197)[:1.7.0_55]
>         at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)[:1.7.0_55]
>         at org.eclipse.jetty.io.nio.ChannelEndPoint.fill(ChannelEndPoint.java:186)[260:org.eclipse.jetty.io:7.5.4.v20111024]
>         at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.fill(BlockingChannelConnector.java:237)[264:org.eclipse.jetty.server:7.5.4.v20111024]
>         at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:949)[265:org.eclipse.jetty.http:7.5.4.v20111024]
>         at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:274)[265:org.eclipse.jetty.http:7.5.4.v20111024]
>         at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)[265:org.eclipse.jetty.http:7.5.4.v20111024]
>         at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:50)[264:org.eclipse.jetty.server:7.5.4.v20111024]
>         at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:293)[264:org.eclipse.jetty.server:7.5.4.v20111024]
>         at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)[268:org.eclipse.jetty.util:7.5.4.v20111024]
>         at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)[268:org.eclipse.jetty.util:7.5.4.v20111024]
>         at java.lang.Thread.run(Thread.java:745)[:1.7.0_55]
> 16:17:23,334 | DEBUG | qtp1008596480-32 | HttpConnection                   | 268 - org.eclipse.jetty.util - 7.5.4.v20111024 | closed org.eclipse.jetty.server.BlockingHttpConnection@799e037@127.0.0.1:10080<->127.0.0.1:49261
>
> So ..
>
> (1) How can I catch the IOException in Jetty?
>
> (2) Since I’m running ServiceMix 4.5.3 what is the procedure to get it done in this runtime?

The problem is that your write which you are performing from your
application does *not* throw the exception, which is instead thrown by
a subsequent read.
So from the application point of view, you got a request, waited 15s,
wrote some content back without error, done.
Servlet containers are not supposed to tell the application about
*read* failures that happen between requests, so there is no standard
way to catch those.

If you want some kind of reliability, you need to come up with some
application protocol: e.g. the client sends the server an ack of
received content.
There are a million different ways of doing this, depending exactly on
your use case.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.

Back to the top