Hi, > 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.
Yes, but this is not done by me and I thought this belongs to the jetty implementation. > So from the application point of view, you got a request, waited 15s, > wrote some content back without error, done. Totally agreed. > 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. Totally agreed. Because of that is was looking for some kind of method/way to register an exception handler which is called in this cases. I think the point is, that if you are running a web server you do not really care if the session is closed before providing the result. Running a server which exposes some service changes the need in this cases. > > 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. Agreed, but I can’t change the requesting application. It’s a behaviour of the requesting legacy system that is closes the session if the query is running to long and it expects the result on a JMS queue. The timeout is determined by the use case the called service is not aware of. So I don’t know how much time I have to complete. The current implementation handles this by customising Tomcat 6. I have to reimplement it on SMX and would like to avoid customising jetty or tomcat. Is there really no standard way to catch those IOExceptions? thanks + best regards harald _______________________________________________ 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
