Hi Simone,

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 inside FF.



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

Reply via email to