I agree, if your application is basically a WAR, 256MB for the JVM may be fine. However, an EAR that contains several MDB's/EJB's that concurrently service high volume queues and make calls to a database that can return 10,000 records each that are then build in a collection and distributed back to a client would obviously need
ALOT more heap. I understand why you use 2gig JVM(use
EJB's too?). alot of system admins do not understand that it is the system RAM/ application that should dictate this, not a cookie cutter standard.
We had severall issues on a prototype, yes getting the infamous outOfMemory exception, and we are currently workig towards:
-raising the JVM heap to at least 1.5 gig
-clustering WAS instances allowing us to lower the number of connection pools for the MDB's/ stateless Session bean(that use MQ) and
JDBC pool Intern cluster
it takes alot of performance
testing and probr moitoring to configure this
any thoughts?