Avoiding java.lang.OutOfMemoryError when installing application with wsadmin
timdp 2000003V97 Visits (11933)
Just a quick one here, but I recently encountered a situation where we received a java
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:
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: