Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
Alexander Klimetschek skrev:
the ResourceReader must throw any IOException caught in generate()
(line 349). This is currently not done because it looks like there
are cases, where a failed generate should be silently ignored. The
debug message says "Received an IOException, assuming client severed
connection on purpose".
Is this true? Or would it be no harm to throw the exception at that
place to trigger the standard "Problem in creating the Request" page?
No idea why the code just swallow the exception. IMO it is a bad idea.
If there is any sources that throw Exceptions without meaning anything
with it, it should be fixed there instead.
I would assume that it fixes some issue but couldn't find any
information about it in the SVN log.
Anyone who know anything about it?
IIRC, when client terminates the connection prematurely (stops the
download midway), you would want to:
*) stop request processing
*) do not show error page
While this code is probably still working for non-caching pipelines
(reader writing directly to socket), I'm not sure that this particular
scenario is still possible with caching pipeline (where reader would
write to in memory buffer).
See also CocoonServlet (2.1) lines 1183-1198.
Thanks. I checked in the code and it seem like the reason that an
IOException is catched instead of a SocketException is that Tomcat5
wraps the SocketException in some other exception class that implements
IOException but not SocketException.
Anyway, both SocketException and IOException are wraped in
o.a.c.ConnectionResetException in the
AbstractProcessingPipeline.handleException. And the situation is
(again?) handled in the requestProcessor.service.
So I don't see any reason that the situation should be handled at all in
the ResourceReader.
So I'll remove the catch statement in the ResourceReader and make my
self prepared to revert it (or find some other fix) if any problems are
reported.
/Daniel
