[jBPM] - jBPM session persistence - "Removing a detached instance" encountered under load / concurrency
by Mark Egan
Mark Egan [https://community.jboss.org/people/xmrk] created the discussion
"jBPM session persistence - "Removing a detached instance" encountered under load / concurrency"
To view the discussion, visit: https://community.jboss.org/message/778981#778981
--------------------------------------------------------------
I'm encountering an exception with jbpm-persistence-jpa when performing load testing on an application-embedded jBPM. The stack trace is:
Caused by: java.lang.IllegalArgumentException: Removing a detached instance org.drools.persistence.info.WorkItemInfo#234
at org.hibernate.ejb.event.EJB3DeleteEventListener.performDetachedEntityDeletionCheck(EJB3DeleteEventListener.java:67) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at org.hibernate.event.internal.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:107) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
at org.hibernate.event.internal.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:74) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
at org.hibernate.internal.SessionImpl.fireDelete(SessionImpl.java:822) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
at org.hibernate.internal.SessionImpl.delete(SessionImpl.java:801) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
at org.hibernate.ejb.AbstractEntityManagerImpl.remove(AbstractEntityManagerImpl.java:883) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at org.drools.persistence.jpa.JpaPersistenceContext.remove(JpaPersistenceContext.java:54) [drools-persistence-jpa-5.5.0.Final.jar:5.5.0.Final]
at org.drools.persistence.jpa.processinstance.JPAWorkItemManager.completeWorkItem(JPAWorkItemManager.java:123) [drools-persistence-jpa-5.5.0.Final.jar:5.5.0.Final]
I'm using 5.4.0.Final (however I observed the same behavior in 5.3.0.Final and 5.4.0.CR1). The application server is JBoss AS 7. I'm using MySQL InnoDB having row-locking enabled.
The process calls EJBs within separate WorkItemHandlers. Here's the basic process:
1) start process,
2) call a local, no-interface EJB (injected with @Inject) and persist a domain object (using a separate persistence context),
3) lookup another EJB (using InitialContext.doLookup) and perform some synchorous work,
4) end process.
I'm initiating the process from a REST endpoint. The jBPM session.startProcess(...) occurs in a Local EJB exposed service.
The load test calls the REST endpoint. I'm using jMeter. The thread group only consists of 2 threads. There is a short ramp-up.
Here's a rundown of my observations:
During ramp-up where the process service is a single thread, no issues are observed. Once the second thread spins up, the exception is received on all subsequent calls. The WorkItemInfo which fails to be removed is for step #2 (the local EJB call to a separate persistence service). If I remove the third step from the definition, the issue is not observed.
Here's my Environment for the JPAKnowledgeService.newStatefulKnowledgeSession(...).
@Produces
public Environment getEnvironment() {
Environment env = KnowledgeBaseFactory.newEnvironment();
env.set(EnvironmentName.ENTITY_MANAGER_FACTORY, emf);
env.set(EnvironmentName.TRANSACTION_MANAGER, new ContainerManagedTransactionManager());
env.set(EnvironmentName.PERSISTENCE_CONTEXT_MANAGER, new JpaProcessPersistenceContextManager(env));
return env;
}
I'm only using a session once and dispose of it after a single process completes.
I'm setting the following for my persistence context:
hibernate.transaction.factory_class=org.hibernate.transaction.CMTTransactionFactory
I understand that what I'm encountering could be related to general container handled transactions across my EJB calls, but I wanted to start with the jBPM community. I had already investigated the transaction handling on those EJB calls and wasn't able to resolve the issue using various @TransactionAttribute or alterations to the persistence context's properties.
I also reviewed the persistence chapter in the 5.4 User Guide: http://docs.jboss.org/jbpm/v5.4/userguide/ch.core-persistence.html http://docs.jboss.org/jbpm/v5.4/userguide/ch.core-persistence.html, as well as the Multi-Threading section: http://docs.jboss.org/jbpm/v5.4/userguide/ch.core-basics.html#d0e2358 http://docs.jboss.org/jbpm/v5.4/userguide/ch.core-basics.html#d0e2358.
Any help is appreciated.
Thanks,
-mark
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/778981#778981]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 4 months
[Performance Tuning] - jboss cpu spike - GC?
by jboden
jboden [https://community.jboss.org/people/jboden] created the discussion
"jboss cpu spike - GC?"
To view the discussion, visit: https://community.jboss.org/message/762252#762252
--------------------------------------------------------------
Hi,
I have a jboss 5.1 app with sun jdk 1.7.something. At night, it runs a large job and gobbles memory. The process gets to 2.5GB and never goes down, but I hear that's normal with heap space? But after a few days of this, I begin to see the cpu spike to 100% of one cpu for a few seconds, then go down. This happens every 5 seconds or so, probably GC?
Using mostly a default run.bat, I have the jvm args set to:
-Xrs -Xms256M -Xmx2048M -XX:MaxPermSize=256m -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC
-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
-Dorg.jboss.resolver.warning=true
Should we be doing something more specific? And if the GC keeps running that often even after the thread to do the nightly job has ended, do I have a memory leak somewhere? We do sometimes run out of memory, but maybe it needs Xmx of 4gb just to finish the job.
I'm going to up the memory anyway, but what clues do we look for to determine if there is a leak and/or better GC settings?
Thank you very much!
Jim
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/762252#762252]
Start a new discussion in Performance Tuning at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 4 months
