JSPs generally use the <jsp:useBean> tag to provide themselves with access to beans in various scopes, such as:

<jsp:useBean id="someResult" scope="session" class="com...SearchResult" />

This tag is particularly expensive when the bean in question does not exist in the referenced scope. In this case the Beans framework goes off looking for a serialized bean on the classpath before eventually instantiating a new object through reflection. For each bean instantiated in this way there is ~100KB of memory cycled.

Optimization options:

1) Use a scriptlet to grab a reference from the request and/or session, check for the presence of the bean, and instantiate manually if required.

2) Always ensure the referenced objects are present in scope. Risky, but if you are a devoted JSTL user, then you must track your references from page to page.

Came across this error log entry where the application was occasionally spewing:

[7/25/07 10:31:42:485 CDT] 0000011a SRTServletReq E SRVE0133E: An error occurred while parsing parameters. java.io.IOException: SRVE0216E: post body contains less bytes than specified by content-length

Looks like there is a problem with automatic decompression in WAS. From PK41619:

The auto decompression of messages does not happen until the reads of body data starts. This means that the Content-Length header prior to this point will report the compressed length, but after the decompression happens, it is updated with the decompressed length. The HttpInputStream class is storing the original length and never seeing the new length.

IBM has fixes available for WAS versions 6.0.2.19 and 6.1.0.9.