Relic Solution: JSPs are not loading when adding the Java Agent

In Tomcat (and other web application servers) there is a way to set the size of the output buffer (when writing out the response) such that after a certain size it will automatically start flushing the data to the client and “commit” the response. This issue is caused when a JSP is almost to the buffer limit (default 8192) and then enabling browser monitoring with auto_instrument: true.
Under normal circumstances this is totally fine on its own and would just work without anyone noticing but in the case of important pages (such as authentication pages, healthcheck endpoints, and others) it did not perform as anticipated, surfacing an exception and returning a 200 response. This is actually the expected behavior given the default configuration of the Tomcat application server.

The components responsible for this behavior are:

JspWriter - JspWriter (JSP 2.3 API Documentation - Apache Tomcat 8.0.53)

  • The main class responsible for creating the JspWriter object which writes the actions and template data in a JSP page:
protected JspWriter(int bufferSize,
boolean autoFlush)

It takes the following two parameters:

bufferSize - JspWriter (JSP 2.3 API Documentation - Apache Tomcat 8.0.53). The size of the buffer to be used by the JspWriter. Defaults to 8kb in the versions of Tomcat that I’ve tested so far.

autoFlush - JspWriter (JSP 2.3 API Documentation - Apache Tomcat 8.0.53). Whether the JspWriter should be autoflushing. Defaults to true.

Here is a breakdown of the parameters: Apache Tomcat JspWriter docs


The initial JspWriter object is associated with the PrintWriter object of the ServletResponse in a way that depends on whether the page is or is not buffered. If the page is not buffered, output written to this JspWriter object will be written through to the PrintWriter directly, which will be created if necessary by invoking the getWriter() method on the response object. But if the page is buffered, the PrintWriter object will not be created until the buffer is flushed and operations like setContentType() are legal. Since this flexibility simplifies programming substantially, buffering is the default for JSP pages.

Buffering raises the issue of what to do when the buffer is exceeded. Two approaches can be taken:

  • Exceeding the buffer is not a fatal error; when the buffer is exceeded, just flush the output.
  • Exceeding the buffer is a fatal error; when the buffer is exceeded, raise an exception.

Both approaches are valid, and thus both are supported in the JSP technology. The behavior of a page is controlled by the autoFlush attribute, which defaults to true. In general, JSP pages that need to be sure that correct and complete data has been sent to their client may want to set autoFlush to false, with a typical case being that where the client is an application itself. On the other hand, JSP pages that send data that is meaningful even when partially constructed may want to set autoFlush to true; such as when the data is sent for immediate display through a browser. Each application will need to consider their specific needs.

An alternative considered was to make the buffer size unbounded; but, this had the disadvantage that runaway computations would consume an unbounded amount of resources.

The “out” implicit variable of a JSP implementation class is of this type. If the page directive selects autoflush="true" then all the I/O operations on this class shall automatically flush the contents of the buffer if an overflow condition would result if the current operation were performed without a flush. If autoflush="false" then all the I/O operations on this class shall throw an IOException if performing the current operation would result in a buffer overflow condition.

With best practices in mind, there are a few options available for mitigating this issue going forward: