Some development teams I work with have been reporting an issue where the JVM runs out of memory during deployment of an application using our standard heap size settings (initial 2 GB and maximum 2 GB). When they changed the initial heap size from 2 GB to 512 MB, the no longer receive the OutOfMemory error. To understand what’s happening, continue on. (more…)
My colleague Phil gave me a simple but effective breakdown of the difference between these two settings in WebSphere Application Server. Here he describes the shared setting:
Shareable tells the WAS container, when a servlet transport thread closes a connection, don’t actually put that connection back in the pool. Instead, keep it in some local context so that the thread can get access to it when it asks again during the processing of this request. Then finally, when the request is completed, then put the connection back in the pool.
Shareable is an optimization. You would use this for connections which you know will be used many times during processing of a single request. WPS database connections are a good example. We always recommend the number of WPS portal database connections equal the number of web container thread pool size to avoid queuing for portal database connections. I’ve never seen an application database connection that would need to gain from using shareable connections.
The downside of shareable is that if you use it when you don’t need it, you need a larger pool of connections than you would with unshareable connections in order to avoid a connection bottleneck since each thread is holding a connection for a longer period of time.
He goes on to describe the unshared setting:
Unshareable has the opposite behavior. When a thread closes a connection, the thread puts the connection back in the pool.
As an aside if you don’t have a resource-ref defined with shareable/unshareable property and/or don’t use this ref name in the code - you will get shareable by default - with a warning in wps.err/out. In this circumstance your pool size may be causing queuing if the size of the connection pool is less than the size of the thread pool. We suggest to use a resource-ref and set this to unshareable for applications.
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.