tags:

views:

1996

answers:

2

Is there a way to set the default buffer size for JSPs in Tomcat? I know I can set them on every page, but am hoping there's a global option somewhere.

+1  A: 

EDIT: To lift the comments discussion to this answer - this might be what you're after

When you're stuck with a legacy application even without separation of processing (controller) and view (jsp), you should limit your processing to the very first instructions on a jsp, e.g. right on top. There you're even free to redirect (e.g. send back response code 302), let alone signal errors with the correct error code. That said, you should avoid presenting 500 style errors to your customers anyway. Rather deliver a nice looking html page (200), displaying a helpful error message to the customer. Applications should display their errors on their level, not on a protocol level.

I remember, back in the last century, to have worked on such an application myself. We have experienced some platform differences: One platform didn't buffer even the first byte but immediately sent it back to the customer, rendering our redirection attempts (code 302) useless, as the 200-code header was already on it's way. The only thing that helped was to make sure that not a single byte could have been sent prior to the processing. As we've needed some taglibs, we've had to eliminate the linebreaks between taglib instructions. There's two ways to do this:

Instead of

<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt" %>
<% /* your processing instructions here */ 
   response.sendRedirect("somewhere.jsp") %>

write

<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" 
%><%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt"
 %><% /* your processing instructions here */ 
   response.sendRedirect("somewhere.jsp") %>

or use jsp comments to eliminate line breaks:

<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %><%-- 
--%><%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt"%><%--
--%><% /* your processing instructions here */ 
   response.sendRedirect("somewhere.jsp") %>

This might look ugly but greatly reduces the danger of the server flushing the buffer - no matter how big it might be.

Hope this helps.


This is what was answered prior to / during the comments discussion

The Tomcat docs for the http connector have bufferSize, socketBuffer and several more options for the nio installation - some for input- and some for output streams. The AJP connector seems not to be that configurable (you need the ajp connector if you use Apache/mod_jk).

I hope that the buffer you're looking for is among these...

EDIT: (The comment space has been too small, so I chose to add some more information regarding your comment that you use AJP here:)

The wisdom about buffer sizes seems to be implemented (from a brief look at the tomcat 6.0.18 source code) in org.apache.catalina.connector.OutputBuffer and in org.apache.catalina.connector.Response. Of particular interest is this piece of code (from Response):

/**
 * Set the Connector through which this Request was received.
 *
 * @param connector The new connector
 */
public void setConnector(Connector connector) {
    this.connector = connector;
    if("AJP/1.3".equals(connector.getProtocol())) {
        // default size to size of one ajp-packet
        outputBuffer = new OutputBuffer(8184);
    } else {
        outputBuffer = new OutputBuffer();
    }
    outputStream = new CoyoteOutputStream(outputBuffer);
    writer = new CoyoteWriter(outputBuffer);
}

Basing my judgement on this piece of code, it seems that increasing buffer size might not really be helping your issues. Not that I would like to say that it doesn't help... Did you measure actual performance when you increase buffer size from jsps? Does it help to do so?

With the knowledge of this point of contact you might suffice by either patching the tomcat source or by adding a filter to your web application or tomcat container configuration that tweaks the buffer size according to your needs. (I'd prefer the filter over the tomcat patch any time)

Another idea that comes to my mind is: If you use any templating system (like tiles, as you are mentioning jsp, but velocity or others come to mind) you shouldn't have too many points where you'd have to set the buffer size from jsps. In systems I've worked on I probably would guess that around 10 basic layout templates would be affected (independent of project size).

I hope that this addition helps...

Olaf
We use the AJP connector, so no luck there.
hlavka
I've edited my answer to reflect this aspect - please read there.
Olaf
The real problem we are trying to solve is that once the buffer flushes, we can no longer redirect. This means that 500 errors that occur after the first flush do not get redirected to our 500 page and are not reported as 500s in the access logs.
hlavka
Ok, got it. Why didn't you ask this? ;-) I wouldn't try to solve this with the buffer size - this imposes severe limits on your scalability. When the jsp is showing, processing should be done and 500s shouldn't occur - only errors in the visualization are allowed. What env./framework are you using?
Olaf
You're right... I should have started here. It is legacy code -- no framework, straight JSPs.
hlavka
+2  A: 

Short answer: No.

Long answer: Perhaps, with some hacking...

  • You'd have to build Tomcat yourself after editing this class: Jasper constants
  • ...or you can do a Perl pie, and edit all your JSPs all at once. Back-up first as this edits in-line:

For directives without the buffer set:

/usr/bin/perl -pi -e 's|<%@ page|<%@ page buffer="new" |g' `find . -type f -name '*.jsp'`

For already-set buffers:

/usr/bin/perl -pi -e 's|buffer="old"|buffer="new"|g' `find . -type f -name '*.jsp'`

(If your directives are inconsistent with the above, e.g. more/less whitespace, please use more regexp magic to make it work)

Your problem elsewhere on the web: http://www.theserverside.com/discussions/thread.tss?thread_id=24768

HTH

opyate
This is basically what we ended up doing.
hlavka
building Tomcat, or Perl pie?
opyate