Just a quick one here, but I recently encountered a situation where we received a java.lang.OutOfMemoryError whilst developing a script to perform an automated installation of a large EAR file (>100mb) using wsadmin.
In a standalone application server (default profile), wsadmin creates its own JVM, and this is used for application unpack and installation. My initial thought was to use the -javaoption parameter of wsadmin to pass in my own -Xmx value to increase the heap size. Unfortunately, wsadmin is written in such a way that when it creates its JVM, your -javaoption parameter is passed in on the command line before it's own internal PERF_JVM_OPTIONS parameter which specifies -Xmx. When the JVM receives two -Xmx arguments, the latter takes precedence (although, when I checked this with a colleague in our Java Technology Centre, he said that the JVM sent him an email and he flipped a coin!), so to work around this you must do one of two things:
- Edit wsadmin so that javaOption (this is the variable inside wsadmin that the -javaoption parameter is stored into) occurs after PERF_JVM_OPTIONS, and pass -javaoption into wsadmin setting -Xmx. This is documented here.
- Update the setting of PERF_JVM_OPTIONS directly in wsadmin.
In a clustered environment, wsadmin always connects to the Deployment Manager, and application unpack and installation occurs on the nodeagent of each node. This meant that in our clustered install script, before we installed the application to the cluster, we had to loop through all nodeagents and set the process defition - > Java virtual machine properties to increase the heap size and then perform a restart for the new settings to take effect. We were using the excellent wsadminlib.py as an accelerator and were able to use the listNodes, setJVMProperty and restartServer functions to fully automate this process.
The final tweak we had to make was handling the case where a custom node has been cloned to create a new node as part of a running virtual systems pattern. In this instance, we were using the advanced options of IBM Workload Deployer to create our cluster for us, and this meant that our script package was invoked after the node had been created and federated into the cell. In a clone operation, here's what happens when you're using IWD to create your cluster:
- IWD creates the new custom node virtual machine and starts it.
- Once the virtual machine has started and WAS has been installed, the new custom node is federated to the Deployment Manager and the IWD cluster creation scripts create the specified number of new cluster members (servers) on the new node.
- Once the cluster members are created, the Deployment Manager pushes the application over to the nodeagent on the new custom node.
- As the nodeagent still has it's default heap size, the application install causes the nodeagent to OoM.
- Our script package executes on the new custom node and increases the nodeagent heap size.