Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Catching on the server side


> 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

Back to the top