[
https://jira.jboss.org/jira/browse/JBPM-2202?page=com.atlassian.jira.plug...
]
Alejandro Guizar updated JBPM-2202:
-----------------------------------
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
was:
39 unique processes
243 entries in jbpm.jbpm_processdefinition
ach process has ~6 versions deployed, of which only the most recent version is in daily
usage
ehcache is configured as the hibernate cache.
Description:
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.
was:
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.
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
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