8:39 a.m.
QA job executor
---------------
Key: JBPM-1280
URL: http://jira.jboss.com/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PVM
Reporter: Tom Baeyens
First, we need to establish what we're going to QA and how. I see 3 distinct types of
tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways to
deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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:17 p.m.
New subject: [JBoss JIRA] Assigned: (JBPM-1280) QA job executor
[ http://jira.jboss.com/jira/browse/JBPM-1280?page=all ]
Alejandro Guizar reassigned JBPM-1280:
--------------------------------------
Assignee: Alejandro Guizar
QA job executor
---------------
Key: JBPM-1280
URL: http://jira.jboss.com/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assigned To: Alejandro Guizar
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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:23 p.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) QA job executor
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Alejandro Guizar updated JBPM-1280:
-----------------------------------
Fix Version/s: PVM 1.0 beta1
QA job executor
---------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Alejandro Guizar
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
7:51 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) QA job executor
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-1280:
------------------------------
Priority: Critical (was: Major)
QA job executor
---------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Alejandro Guizar
Priority: Critical
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
2:28 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) QA job executor
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-1280:
------------------------------
Issue Type: Sub-task (was: Task)
Parent: JBPM-1430
QA job executor
---------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Alejandro Guizar
Priority: Critical
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
2:46 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-1280:
------------------------------
Summary: build out job executor basic test coverage (was: QA job executor)
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Alejandro Guizar
Priority: Critical
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
2:50 a.m.
New subject: [JBoss JIRA] Assigned: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens reassigned JBPM-1280:
---------------------------------
Assignee: Guillaume Porcher (was: Alejandro Guizar)
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Guillaume Porcher
Priority: Critical
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
4:25 a.m.
New subject: [JBoss JIRA] Commented: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-1280:
-----------------------------------
tests that do waiting should not be included in the CheckIn tests
tests that require read-committed isolation level should not be included in the CheckIn
tests. they should only be run in the continuous integration environment on databases
that support proper isolation level
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Guillaume Porcher
Priority: Critical
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
4:34 a.m.
New subject: [JBoss JIRA] Commented: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-1280:
-----------------------------------
an important part of this task is the systematic approach. meaning that i don't want
tests to be created ad hoc cause then we'll never know what we test and what not.
that doesn't mean that all possible combinations have to be tested. but i want that
we at least thought about which combinations we want to see tested. by having an overview
that has a systematic approach, we can get a good appreciation of the coverage of the test
suite for the job executor
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Guillaume Porcher
Priority: Critical
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
4:39 a.m.
New subject: [JBoss JIRA] Commented: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-1280:
-----------------------------------
It's crucial that the job executor is tested on edge cases. Not only the normal
rollback and commits. But also 3 tests with a synchronizationsin the same
transaction:
* one that just does a transactional update to the db and succeeds
* one that throws an exception in the beforeCompletion (should cause a rollback of the
transaction)
* one that throws an exception in the afterCompletion (should cause the rest of the
transaction to commit)
Probably there are more of those specific situation that we need to cover.
I have started with the checking the basics in org.jbpm.pvm.api.db.tx.TransactionDbTest.
That test I just added to the CheckInTests. That test can give some inspiration on how to
find the edge cases for the job executor.
I have put the TransactionDbTest in the API part as I think it should run in any
environment.
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Guillaume Porcher
Priority: Critical
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
2:30 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Thomas Diesler updated JBPM-1280:
---------------------------------
Fix Version/s: PVM 1.0.0 Beta2
(was: PVM 1.0.0 Beta1)
Deferred to Beta2
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Guillaume Porcher
Priority: Critical
Fix For: PVM 1.0.0 Beta2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
3:29 a.m.
New subject: [JBoss JIRA] Assigned: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens reassigned JBPM-1280:
---------------------------------
Assignee: (was: Guillaume Porcher)
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Priority: Critical
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
3:29 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-1280:
------------------------------
Fix Version/s: jBPM 4.0.0 Alpha2
(was: jBPM 4.0.0 Alpha1)
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Priority: Critical
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
7:48 a.m.
New subject: [JBoss JIRA] Commented: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-1280:
-----------------------------------
http://hudson.qa.jboss.com/hudson/view/JBPM4/job/jbpm4-base/
shows some random failures in the basic job executor tests. probaably due to isolation
level. which i thought would not matter in these test cases...
anyway. this needs to be looked at.
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Priority: Critical
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
7:50 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-1280:
------------------------------
Parent: (was: JBPM-1430)
Issue Type: Task (was: Sub-task)
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Priority: Critical
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
8:10 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-1280:
------------------------------
Priority: Major (was: Critical)
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
8:30 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-1280:
------------------------------
Assignee: Tom Baeyens
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Tom Baeyens
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
11:16 a.m.
New subject: [JBoss JIRA] Commented: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-1280:
-----------------------------------
Running org.jbpm.pvm.internal.jobexecutor.ContinuationTest
### EXCEPTION ###########################################
18:11:52,988 SEV | [AbstractFlushingEventListener] Could not synchronize database state
with session
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction
(or unsaved-value mapping was incorrect): [org.jbpm.pvm.internal.model.ExecutionImpl#1]
at
org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1769)
at
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2412)
at
org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2312)
at
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2612)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:96)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168)
at
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at
org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at
org.jbpm.pvm.internal.tx.HibernateSessionResource.prepare(HibernateSessionResource.java:54)
at
org.jbpm.pvm.internal.tx.StandardTransaction.commit(StandardTransaction.java:106)
at
org.jbpm.pvm.internal.tx.StandardTransaction.complete(StandardTransaction.java:65)
at
org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:61)
at
org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:52)
at
org.jbpm.pvm.internal.jobexecutor.JobExecutorThread.run(JobExecutorThread.java:62)
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Tom Baeyens
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
5:20 a.m.
New subject: [JBoss JIRA] Updated: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens updated JBPM-1280:
------------------------------
Priority: Critical (was: Major)
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Tom Baeyens
Priority: Critical
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
6:14 a.m.
New subject: [JBoss JIRA] Resolved: (JBPM-1280) build out job executor basic test coverage
[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens resolved JBPM-1280.
-------------------------------
Resolution: Done
moved multithreaded job executor tests to test-load module
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL: https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Tom Baeyens
Priority: Critical
Fix For: jBPM 4.0.0 Alpha2
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
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
5796
days inactive
6029
days old
19 comments
3 participants
participants (3)
-
Alejandro Guizar (JIRA) -
Thomas Diesler (JIRA)
-
Tom Baeyens (JIRA)