Out of memory

Hi,

We are migrating from 5.3 to 6.5. After migration method server(Jboss)showing Out OF memory-Heap space after some hours. Increasing heap size doesnt work.So we checked the heap dump and there are lots of weeksessionhandle objects having refrece to persistentcache. We have disabled the persistent cache but that doesnt solve the problem. Will you let me knoe the reaon why cache objects are created and what are weeksessionhandle objects.

Regards

Sunil

java_pid10399_Leak_Suspects.zip

Find more posts tagged with

Comments

XdctmX

Did you folow this note to increase the heap? - https://solutions.emc.com/emcsolutionview.asp?id=esg117360

How to increase JBOSS jvm heap memory

Symptoms

Procedure to increase memory for JBOSS method server to 1GB in D 6.5.

Resolution

Please follow the steps below to adjust JBOSS JVM heap memory values.

On Linux/Unix:

edit $DOCUMENTUM_SHARED/jboss4.2.0/serverstartMethodServer.sh
#!/bin/sh
USER_MEM_ARGS="-Xms1024m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m -Xss256k -XX:+DisableExplicitGC"
export USER_MEM_ARGS
/opt/D65/shared/jboss4.2.0/bin/run.sh -c DctmServer_MethodServer -b 0.0.0.0 $JAVA_OPTIONS

On Windows services:

edit C:\Documentum\jboss4.2.0\server\startMethodServer.cmd
set NOPAUSE=true
set USER_MEM_ARGS=-Xms1024m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m -Xss256k -XX:+DisableExplicitGC -Xrs
C:\Documentum\jboss4.2.0\bin\run -c DctmServer_MethodServer -b 0.0.0.0 %JAVA_OPTIONS%

sky

Yes we did that , and increased the memory to 2GB ,thats why the heap Dump after OUT of memory is of 2GB. But the problem is WeakSessionHandle and PersistentCache objects which are taking about 1.75 GB of memory(See attached report in earlier post). I checked for Session leak using dfc but i did,t get any session leak Also.

This is urgent Please help

Still waiting for help

dnvhariprasad

Did you check these properties?

# Used to control whether a session can be disconnected through a weak session 
# handle. By default such a thing is not allowed because it is dangerous and 
# often a source of application bugs. It is much safer to always disconnect 
# through the strong handle that was obtained at "connect" time. 
# 
# For compatibility with certain older applications you can use this option to 
# enable disconnect through a weak session handle. It is recommended that you 
# avoid using this option. The application should be fixed instead. Enabling 
# this option can allow application logic bugs to cause all sorts of nasty and 
# hard to detect session management problems.                                   
#

dfc.compatibility.allow_weak_disconnect = false

# These messages are usually ignored by applications and sometimes the messages 
# actually get in the way if the application is not careful. It is typically 
# more convenient to simply discard these unnecessary messages to avoid any 
# problems. If,however, your legacy application relies upon the informational 
# messages then you can ask that they be preserved.                             
# 
dfc.compatibility.preserve_session_info_messages = true