Hi, On Wed, Jul 23, 2014 at 5:34 PM, harald <[email protected]> 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@[email protected]: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. _______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
