[
https://jira.jboss.org/jira/browse/JBPM-2202?page=com.atlassian.jira.plug...
]
Alejandro Guizar resolved JBPM-2202.
------------------------------------
Resolution: Done
Created a new SharedProcessClassLoaderFactory implementation which maintains a process
class loader cache.
Modified ProcessClassLoader so that it does not keep a reference to a persistent
ProcessDefinition.
jBPM might be re-loading classes when not strictly necessary
------------------------------------------------------------
Key: JBPM-2202
URL:
https://jira.jboss.org/jira/browse/JBPM-2202
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.5.SP5
Environment: 39 unique processes
243 entries in jbpm.jbpm_processdefinition
~6 versions deployed per process; only the most recent version is in daily usage
ehcache is configured as the hibernate cache
Reporter: Alejandro Guizar
Assignee: Alejandro Guizar
Fix For: jBPM 3.2.7 GA, jBPM 3.2.5.SP6
jBPM creates new Java classes out of binary process definition data stored in the
database. This is needed for different versions of the process. It appears a special
classloader is used for this. In SUN hotspot-class JVMs, parts of these load classes would
be stored in perm gen rather than heap, which is not typically collected until absolutely
necessary, potentially causing high cpu gc thrashing issues. If this was normal objects we
were dealing with, the parallel scavenges or CMS fulls should collect them without
problems. It appears this is not the case.
I believe the issue is that jBPM might be re-loading classes when not strictly necessary.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira