Locking problems when using JBPM with persistence on PostgreSQL
by Alberto R. Galdo
Hi,
We have a system that executes processes inside a JBPM session which is
persisted using JPA and Hibernate as entity manager .
What we are suffering is locking inside JBPM in certain circumstances.
What we experience is that the JBPM process gets locked when in a
transaction to store it's internal state in the database ( sessioninfo,
processinstanceinfo, ... ). When locked PostgreSQL has a connection that is
in state "idle in transation", this means that a transaction was open (
BEGIN ) and nobody did neither commit nor rollback. Both JBPM and
PostgreSQL are waiting for something to happend that never comes. And there
are ExclusiveLocks and RowExclusiveLocks available in the database (
different tables each time, sometimes pg_largeobject, sometimes others ).
Our application that uses extensively JBPM is then locked and our users
are unable to execute any operation. We even tried to solve the lock by
killing the connection to the database, then the locks in the database
dissappear but JBPM never recovers ( maybe died with the connection ).
Has anyone seen something like this before?
Greets,
Alberto R. Galdo
argaldo(a)gmail.com
13 years, 5 months
Drools persistence errors in JBoss 7.x
by Alberto R. Galdo
Hi,
We have an application that uses JBPM and Drools to execute BPMN 2.0
processes. Our knowledge session gets persisted in a PostgreSQL database
and so it is StatefulKnowledgeSession.
Our application runs inside a JBoss 7.x server, our JPA context uses the
bundled Hibernate 4.x as entity manager and JBoss Tx service ( bundled with
jboss) as hibernate's transaction JTA implementation.
From time to time ( we haven't found a way to reproduce this, but clearly
has occurrences in the execution of our application ) we are getting this
kind of exceptions:
Caused by: org.hibernate.exception.GenericJDBCException: Connection is not
associated with a managed
connection.org.jboss.jca.adapters.jdbc.jdk6.WrappedConnectionJDK6@253770bd
during commits induced by Drools
[org.drools.persistence.jta.JtaTransactionManager.commit] ( as you can see
in the full stacktrace attached at the bottom of this mail )
The problem here is that our processes stop executing because of this
exception. For instance, there are times when this exception arises when
commiting a transaction that contains a human task persistance and because
of the exception this information is lost, breaking our processes ( now
nobody will never be ever able to restart the process by completing a human
task ).
Have any of you found this situation before? Any insight?
12:27:47,677 WARN [com.arjuna.ats.arjuna] (pool-11-thread-1) ARJUNA012125:
TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple<
0:ffffc0a802fb:-1f97a856:5093fdd2:620,
org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@79da2820>:
javax.persistence.PersistenceException:
org.hibernate.exception.GenericJDBCException: Connection is not associated
with a managed
connection.org.jboss.jca.adapters.jdbc.jdk6.WrappedConnectionJDK6@253770bd
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at
org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1481)
[hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final]
at
org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109)
[hibernate-core-4.0.1.Final.jar:4.0.1.Final]
at
org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53)
[hibernate-core-4.0.1.Final.jar:4.0.1.Final]
at
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
at
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at
org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:167)
at
org.drools.persistence.jta.JtaTransactionManager.commit(JtaTransactionManager.java:179)
[drools-persistence-jpa-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:376)
[drools-persistence-jpa-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:34)
[drools-persistence-jpa-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:14)
[drools-persistence-jpa-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
[rt.jar:1.6.0_18]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
[rt.jar:1.6.0_18]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
[rt.jar:1.6.0_18]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
[rt.jar:1.6.0_18]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[rt.jar:1.6.0_18]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[rt.jar:1.6.0_18]
at java.lang.Thread.run(Thread.java:636) [rt.jar:1.6.0_18]
Caused by: org.hibernate.exception.GenericJDBCException: Connection is not
associated with a managed
connection.org.jboss.jca.adapters.jdbc.jdk6.WrappedConnectionJDK6@253770bd
Alberto R. Galdo
argaldo(a)gmail.com
-
13 years, 5 months
Drools Guvnor API information?
by Vikas Hazrati
Hi,
I am looking at using Guvnor for our project where users would be creating
rules using our UI. For this i need to add / modify rule or any asset for
that matter using an api.
Unfortunately, i could not find enough documentation to suggest the best way
to use the REST api, which I guess is provided by Guvnor. Could someone let
me know the location of where i can get some information for this api. I
also see that the issue GUVNOR-1080
(https://issues.jboss.org/browse/GUVNOR-1080) is marked resolved so the api
should exist right? or that we cannot access it remotely until we have the
Atom Pub Interface done?
Help appreciated .
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Guvnor-API-inf...
Sent from the Drools - User mailing list archive at Nabble.com.
13 years, 5 months
Error while upgrdaing drools version
by mohan
Hi folks,
I'm using JBoss 5.1.0 GA, Jboss ESB 4.9 and Drool 5.1.0
recently i have tried to upgrade all my entities as below.
*jboss-6.1.0.Final, jbossesb-4.11, drools 5.3.1.Final*
while i start app server i'm getting below error and still i couldn't trace
it. Is it because of compatibility issue or bug? I'm using same drl file as
earlier.
19:01:56,634 ERROR
[org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
installing to Start: name=jboss.esb.vfs:///I:/c
ep/jboss-6.1.0.Final/server/cep/deploy/cep-esb-1.0-SNAPSHOT.esb
state=Create: java.lang.VerifyError: (class: lk/dialog/cep/mobile/Rule_
No_such_offer_yetDefaultConsequenceInvoker, method: evaluate signature:
(Lorg/drools/spi/KnowledgeHelper;Lorg/drools/WorkingMemory;)V)
Expecting to find integer on stack
at java.lang.Class.getDeclaredConstructors0(Native Method) [:1.6.0]
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
[:1.6.0]
at java.lang.Class.getConstructor0(Class.java:2699) [:1.6.0]
at java.lang.Class.newInstance0(Class.java:326) [:1.6.0]
at java.lang.Class.newInstance(Class.java:308) [:1.6.0]
at
org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:409)
[:5.3.1.Final]
at
org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:396)
[:5.3.1.Final]
at
org.drools.rule.JavaDialectRuntimeData.onBeforeExecute(JavaDialectRuntimeData.java:237)
[:5.3.1.Final]
at
org.drools.rule.DialectRuntimeRegistry.onBeforeExecute(DialectRuntimeRegistry.java:132)
[:5.3.1.Final]
at
org.drools.compiler.PackageBuilder.reloadAll(PackageBuilder.java:875)
[:5.3.1.Final]
at
org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:828)
[:5.3.1.Final]
at
org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:404)
[:5.3.1.Final]
at
org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:586)
[:5.3.1.Final]
at
org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:37)
[:5.3.1.Final]
at
org.drools.agent.impl.KnowledgeAgentImpl.createPackageFromResource(KnowledgeAgentImpl.java:712)
[:5.3.1.Final]
at
org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:917)
[:5.3.1.Final]
at
org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:659)
[:5.3.1.Final]
at
org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:190)
[:5.3.1.Final]
at
org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:169)
[:5.3.1.Final]
at
lk.dialog.charging.cep.StatefullCepEngineSingleton.init(StatefullCepEngineSingleton.java:805)
[:]
at
lk.dialog.charging.cep.StatefullCepEngineSingleton.<init>(StatefullCepEngineSingleton.java:83)
[:]
at
lk.dialog.charging.cep.StatefullCepEngineSingleton.intialize(StatefullCepEngineSingleton.java:152)
[:]
at
lk.dialog.charging.cep.feeders.StatefullINUDPVoiceEventFeeder.initialise(StatefullINUDPVoiceEventFeeder.java:30)
at
org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.initialise(ActionProcessingPipeline.java:397)
[:]
at
org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:188)
[:]
at
org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133)
[:]
at
org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:109)
[:
]
kind regards
Mohan
--
View this message in context: http://drools.46999.n3.nabble.com/Error-while-upgrdaing-drools-version-tp...
Sent from the Drools: User forum mailing list archive at Nabble.com.
13 years, 5 months
Reg. Rule parsing & MVEL Dialect
by Phani Saripalli
Hi. Is there any valid impression that MVEL parsing can cause performance
bottlenecks as far is drools is concerned?
Or to put it in a better way, I have 500 rules, patterns for each rule are
bit complex, and my observations are that rule parsing (or grammar
formation) is very time consuming. Would this be better if I use Java
dialect.
To be very precise my issue is, I have a type declaration with 1000
variables and 500 rules. Each rule has a complex pattern. It is taking lot
of time to parse and for the grammar. And secondly, inserting an initial
fact is tending to be time consuming.
Many thanks.
--
View this message in context: http://drools.46999.n3.nabble.com/Reg-Rule-parsing-MVEL-Dialect-tp4020730...
Sent from the Drools: User forum mailing list archive at Nabble.com.
13 years, 5 months
