I'm stuck with OOM while activating changes after we enable HTTP Tunneling on our PROD environment. through Admin console. Tried doing it through WLST aswell but with no luck. It worked well on UAT. I'm wondering why it isn't on PROD,. I'm copying the stack for your reference. Any suggestions on this?
####<Apr 26, 2012 12:01:51 AM EDT> <Error> <Console> <machine01> <AdminServer> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <wlsadmin> <> <> <1335412911650> <BEA-240003> <Console encountered the following error weblogic.management.provider.UpdateException: [Management:141191]The prepare phase of the configuration update failed with an exception:
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: java.lang.OutOfMemoryError: allocLargeObjectOrArray - Object size: 2106432, Num elements: 2106409
What are the memory/heap (Xmx) settings for the JVM of WebLogic Server?
Did you try increasing the Xmx settings?
The only two possibilities for OOM:
1. Genuine usage for which the solution would be to increase the Xmx value of the JVM
2. Memory leak in deployment. (I highly doubt if this is the case. But if increasing the Xmx value did not resolve your issue, then I suggest we try to understand what version of WLS and then also collect verbose:gc information to debug the memory leak)
thanks for the reply. Sorry I didn't mention Heap size in my post. xms and xmx for AdminServer are set to 1.5 GB. Heaap values on same on the managed servers aswell. we are using weblogic version 10.0.0 on windows 32 bit machine.
As it is on production, we can't increase XMX as the whole environment is already stable. As mentioned, I've enabled verbose GC and found the reson
[memdbg ] Thread 441611C8 ([ACTIVE] ExecuteThread: '0' for) stopped roll forwarding (1 times, rfLimit: 100), will sleep and try again.
*[memdbg ] GC reason: TLA allocation failed, cause: Get TLA From Nursery*
[memdbg ] Stopping of javathreads took 0.418 ms
We could find from above that we require more TLA which means more heap size. As you see we are on 32 bit and can't go beyond the current heap.
What I see is, there is something to do with the version we are using. Looking for better suggestions to find a solution for it without changing the current version.
If the OOM error occurs when you deploy for the first time, then we can not really do much here rather than the below two options:
1. If its a big application, then split the application into multiple parts if that is possible, if the application has multiple modules.
2. Increase heap to 1.7GB and hope that small increase will resolve the issue.
If the OOM error is occurring after multiple redeploys, then there is a possibility that you are hitting a bug.
There are a couple of redeployment bugs in WLS10.0. You can request for a fix through a support service request (SR)
Again remember these are bugs related to redeployment only.