[jBPM Users] - Timer throwing exception intermittently
by sridhar18
Hi,
I'm getting the following error at times when my timers are firing.
11:19:51,157 ERROR [ExecuteJobCmd] exception while executing 'timer[46|2009-10-28 11:19:51,040|timeout]'
org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [org.jbpm.pvm.internal.model.ExecutionImpl#152]
at org.hibernate.impl.SessionFactoryImpl$2.handleEntityNotFound(SessionFactoryImpl.java:409)
at org.hibernate.proxy.AbstractLazyInitializer.checkTargetState(AbstractLazyInitializer.java:108)
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:97)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:140)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:190)
at org.jbpm.pvm.internal.model.ExecutionImpl_$$_javassist_4.getActivity(ExecutionImpl_$$_javassist_4.java)
at org.jbpm.pvm.internal.job.TimerImpl.execute(TimerImpl.java:94)
at org.jbpm.pvm.internal.job.TimerImpl.execute(TimerImpl.java:52)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:76)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:42)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.jta.JtaTransactionInterceptor.executeInNewTx(JtaTransactionInterceptor.java:79)
at org.jbpm.pvm.internal.tx.jta.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:61)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.tx.jta.JtaRetryInterceptor.executeWithRetry(JtaRetryInterceptor.java:52)
at org.jbpm.pvm.internal.tx.jta.JtaRetryInterceptor.execute(JtaRetryInterceptor.java:45)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:46)
at org.jbpm.pvm.internal.jobexecutor.JobParcel.run(JobParcel.java:48)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
Sample timer in my process definition:
| <state g="138,450,127,52" name="Validate">
| <on event="timeout">
| <timer name="checkValidity" duedate="3 minutes" repeat="2 minutes"/>
| <event-listener class="some.class.CheckValidityEvent">
| <field name="idType"><string value="ID"/></field>
| </event-listener>
| </on>
| <transition g="-72,-22" name="valid" to="complete"/>
| <transition g="-72,-22" name="invalid" to="end"/>
| </state>
|
The timers tend to exist though and run just fine on the next timeout.
I'm using jbpm 4.1 on jboss 5.1. Thanks in advance.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262812#4262812
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262812
16 years, 6 months
[Persistence] - Isolated ears with same name persistence unit
by icordoba
Hello,
I am deploying two different apps in two ears in JBoss 5.1. They deployed OK in JBoss 4.
As I reuse compiled JEE5 classes and I use annotations, the persistence unit used in both application has the same name: "mainPersistenceUnit" (it has to be hardcoded). this was not a problem with JBoss 4; in the "persistence.xml" archive in the EJB jar I point to each different data source.
The problem is that when starting JBoss 5.1, the second .ear won't load and throw the following exception:
| 2009-10-28 20:24:53,064 WARN [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (main) Unable to register deployment mbean org.jboss.metadata.jpa.spec.PersistenceUnitMetaData.mainPersistenceUnit
| javax.management.InstanceAlreadyExistsException: jboss.deployment:id="org.jboss.metadata.jpa.spec.PersistenceUnitMetaData.mainPersistenceUnit",type=Component already registered.
| at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
| at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
| at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
| at java.security.AccessController.doPrivileged(Native Method)
| at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
| at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
| at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1030)
| at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:722)
| at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
| at org.jboss.deployers.spi.deployer.helpers.ComponentAdapter.addComponent(ComponentAdapter.java:59)
| at org.jboss.deployers.spi.deployer.helpers.AbstractDeploymentVisitor.deploy(AbstractDeploymentVisitor.java:73)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
| at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
|
I've tried all possible isolated / CallByValue / Java2ParentDeletation / etc. on / off configurations.
The weird thing is that, once JBoss has started, I "touch" the second ear and it will deploy without problems.
Thanks for any help/directions.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262803#4262803
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262803
16 years, 6 months
[Installation, Configuration & Deployment] - Re: Multiple JBoss instances vs. one
by icordoba
Hello,
thanks for the links. I had of course read them before posting but, sorry, I can't find definite information there about having to activate CallByValue. I'm sure I'm missing something.
In my scenario I have to deploy two .ears and two .wars. I use classloading configuration for 2 different repositories in jboss-web.xml and jboss-app.xml
I need to do this as I cannot include the war's inside the .ears.
In JBoss I am activating isolation in ear-deployer-jboss-beans.xml but deactivating CallByValue. I also deactivate CallByValue in jboss-service.xml
In war-deployers-jboss-beans.xml I deactivate java2ClassLoadingCompliance, as well as in jboss-app.xml and jboss-web.xml
This should enable isolation while not activating CallByValue.
I'll make checks with both apps. If anybody knows any configuration file I might me missing please point me to any direction.
Thanks,
Ignacio
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262797#4262797
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262797
16 years, 6 months