I should have provided you with more information. Yes, the stack-trace
does come from a printStackTrace that is in our application. The
application is a generic scripting engine that consists of a single
Servlet. This servlet dispatches incoming requests to scripts which
implement our applications. Most error/exception handling is done inside
the scripts themselves but at the highest level uncaught exceptions are
printed to stderr using printStackTrace. That is how these stack traces
end up in the Eclipse console or the application logs.
Apart from the JVM stack traces we also have application stack traces in
terms of the script code. The exceptions all lead to a tiny script class
that implements a handler for static resources. Basically it does some
standard HTTP header handling (If-Modified-Since) and either returns a
304 or sets a Content-Length, Content-Type, Last-Modified, optional
Cache-Control (max-age), transfers all bytes from a BufferedInputStream
to a BufferedOutputStream(response.getOutputStream) (loosely translated
from scripting code) and finally closes the streams.
Please see my response to your other mail for more info on what happens
On 12/3/19 12:45 PM, Simone Bordet wrote:
On Tue, Dec 3, 2019 at 12:26 PM Simone Bordet <sbor...@webtide.com> wrote:
The stack trace shows clearly that it's the client sending a reset to
the server, and that is logged at WARN level; we can certainly improve
the logging as EofException should not be logged at WARN level.
Now that I look better at this, we do print a line a WARN level, but
the whole stack trace is only printed at DEBUG level
May your application have some printStackTrace() left around?
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit