1:45 p.m.
CLONE -concurrent job acquirement fails
---------------------------------------
Key: JBPM-995
URL: http://jira.jboss.com/jira/browse/JBPM-995
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Reporter: Edward Staub
Assigned To: Tom Baeyens
when more than 1 job executor thread is configured and concurrent async nodes are to be
executed, it results in hibernate exceptions.
reason: job acquirement is not synchronized well, resulting in multiple threads trying to
work on the same job.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:08 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-995) CLONE -concurrent job acquirement fails
[ http://jira.jboss.com/jira/browse/JBPM-995?page=all ]
Edward Staub updated JBPM-995:
------------------------------
Description:
when more than 1 job executor thread is configured and concurrent async nodes are to be
executed, it results in hibernate exceptions.
reason: job acquirement is not synchronized well, resulting in multiple threads trying to
work on the same job.
In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been
closed. So I cloned it here.. let me know if that was incorrect process.
The problem was easy to reproduce, and was easy to predict in the first place. Alex's
fix (sychronize on a static class member around acquireJobs()) works for me as well. It
probably trivially improves performance, by avoiding aborted acquire attempts.
As noted in JBPM-974, it only causes an erroneous error message being emitted - the code
operates correctly. It also makes debugging other race conditions much more difficult by
injecting a lot of noise - they usually show up as stale objects as well.
I believe the reason the trace is dumped to the log is because it's dumped at ERROR
level before it even gets to JBPM, in
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions. So the
"catch (StaleStateException e)" doesn't suppress it - the horse has left the
barn, the train has left the station, the s--t has already hit the fan - pick your
favorite metaphor.
was:
when more than 1 job executor thread is configured and concurrent async nodes are to be
executed, it results in hibernate exceptions.
reason: job acquirement is not synchronized well, resulting in multiple threads trying to
work on the same job.
CLONE -concurrent job acquirement fails
---------------------------------------
Key: JBPM-995
URL: http://jira.jboss.com/jira/browse/JBPM-995
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Reporter: Edward Staub
Assigned To: Tom Baeyens
when more than 1 job executor thread is configured and concurrent async nodes are to be
executed, it results in hibernate exceptions.
reason: job acquirement is not synchronized well, resulting in multiple threads trying to
work on the same job.
In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been
closed. So I cloned it here.. let me know if that was incorrect process.
The problem was easy to reproduce, and was easy to predict in the first place.
Alex's fix (sychronize on a static class member around acquireJobs()) works for me as
well. It probably trivially improves performance, by avoiding aborted acquire attempts.
As noted in JBPM-974, it only causes an erroneous error message being emitted - the code
operates correctly. It also makes debugging other race conditions much more difficult by
injecting a lot of noise - they usually show up as stale objects as well.
I believe the reason the trace is dumped to the log is because it's dumped at ERROR
level before it even gets to JBPM, in
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions. So the
"catch (StaleStateException e)" doesn't suppress it - the horse has left the
barn, the train has left the station, the s--t has already hit the fan - pick your
favorite metaphor.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:36 a.m.
New subject: [JBoss JIRA] Closed: (JBPM-995) CLONE -concurrent job acquirement fails
[ http://jira.jboss.com/jira/browse/JBPM-995?page=all ]
Tom Baeyens closed JBPM-995.
----------------------------
Fix Version/s: jBPM jPDL 3.2.2
Resolution: Done
The static synchronization was added on the JobExecutor object.
Furthermore, the logging of optimistic locking failures is made configurable. This is
what was added to the user guide:
6.4. Logging of optimistic concurrency exceptions
When running in a cluster, jBPM synchronizes on the database. By default with optimistic
locking. This means that each operation is performed in a transaction. And if at the end a
collision is detected, then the transaction is rolled back and has to be handled. E.g. by
a retry. So optimistic locking exceptions are usually part of the normal operation.
Therefor, by default, the org.hibernate.StateObjectStateExceptions the that hibernate
throws in that case are not logged with error and a stack trace, but instead a simple info
message 'optimistic locking failed' is displayed.
Hibernate itself will log the StateObjectStateException including a stack trace. If you
want to get rid of these stack traces, put the level of
org.hibernate.event.def.AbstractFlushingEventListener to FATAL. If you use log4j following
line of configuration can be used for that:
log4j.logger.org.hibernate.event.def.AbstractFlushingEventListener=FATAL
If you want to enable logging of the jBPM stack traces, add the following line to your
jbpm.cfg.xml:
<boolean name="jbpm.hide.stale.object.exceptions" value="false"
/>
CLONE -concurrent job acquirement fails
---------------------------------------
Key: JBPM-995
URL: http://jira.jboss.com/jira/browse/JBPM-995
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Reporter: Edward Staub
Assigned To: Tom Baeyens
Fix For: jBPM jPDL 3.2.2
when more than 1 job executor thread is configured and concurrent async nodes are to be
executed, it results in hibernate exceptions.
reason: job acquirement is not synchronized well, resulting in multiple threads trying to
work on the same job.
In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been
closed. So I cloned it here.. let me know if that was incorrect process.
The problem was easy to reproduce, and was easy to predict in the first place.
Alex's fix (sychronize on a static class member around acquireJobs()) works for me as
well. It probably trivially improves performance, by avoiding aborted acquire attempts.
As noted in JBPM-974, it only causes an erroneous error message being emitted - the code
operates correctly. It also makes debugging other race conditions much more difficult by
injecting a lot of noise - they usually show up as stale objects as well.
I believe the reason the trace is dumped to the log is because it's dumped at ERROR
level before it even gets to JBPM, in
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions. So the
"catch (StaleStateException e)" doesn't suppress it - the horse has left the
barn, the train has left the station, the s--t has already hit the fan - pick your
favorite metaphor.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:03 a.m.
New subject: [JBoss JIRA] Commented: (JBPM-995) CLONE -concurrent job acquirement fails
[ http://jira.jboss.com/jira/browse/JBPM-995?page=comments#action_12372284 ]
Ronald van Kuijk commented on JBPM-995:
---------------------------------------
cool... only a strange name for a property.... jbpm.hide...... why not CamelCasing? (me
nitpicking :-) )
CLONE -concurrent job acquirement fails
---------------------------------------
Key: JBPM-995
URL: http://jira.jboss.com/jira/browse/JBPM-995
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Reporter: Edward Staub
Assigned To: Tom Baeyens
Fix For: jBPM jPDL 3.2.2
when more than 1 job executor thread is configured and concurrent async nodes are to be
executed, it results in hibernate exceptions.
reason: job acquirement is not synchronized well, resulting in multiple threads trying to
work on the same job.
In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been
closed. So I cloned it here.. let me know if that was incorrect process.
The problem was easy to reproduce, and was easy to predict in the first place.
Alex's fix (sychronize on a static class member around acquireJobs()) works for me as
well. It probably trivially improves performance, by avoiding aborted acquire attempts.
As noted in JBPM-974, it only causes an erroneous error message being emitted - the code
operates correctly. It also makes debugging other race conditions much more difficult by
injecting a lot of noise - they usually show up as stale objects as well.
I believe the reason the trace is dumped to the log is because it's dumped at ERROR
level before it even gets to JBPM, in
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions. So the
"catch (StaleStateException e)" doesn't suppress it - the horse has left the
barn, the train has left the station, the s--t has already hit the fan - pick your
favorite metaphor.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6624
days inactive
6679
days old
3 comments
3 participants
participants (3)
-
Edward Staub (JIRA) -
Ronald van Kuijk (JIRA)
-
Tom Baeyens (JIRA)