-
1. Re: i'm refactoring child node execution a bit
tom.baeyens Aug 7, 2007 6:25 AM (in response to tom.baeyens)On which pvm classes are you guys working ?
This might become a significant refactoring in the ExecutionImpl class. So merging might become difficult.
Also i'm considering to move the atomic operation implementation classes to top level classes and moving all the process langauge implementation API's to org.jbpm.pvm.impl -
2. Re: i'm refactoring child node execution a bit
mvaldes Aug 7, 2007 9:49 AM (in response to tom.baeyens)On which pvm classes are you guys working ?
Currently only on the get/create/remove child executions methods + related unit tests but I guess that would be easy to merge
in the mean time, it would be good if you could come up with different use cases for concurrency
Basically we were thinking on the following ones:
1.- Transitions based execution with child executions (simple splits and joins). We have already set up some test on that on the unit test called ChildExecutions.java
2.- Nested nodes executions with concurrent executions (i.e simple FLOW)
3.- Transitions based executions mixed with nested nodes (both simple and concurrency use cases). This use case was described here http://jboss.com/index.html?module=bb&op=viewtopic&t=115092
4.- Nested nodes executions with transitions inside. This is a tricky one, I don't know yet if useful (also described in the previous link)
5.- Nested node in the same path of execution + variant of this in which there is another node to the process to be executed (the one you proposed)
In all those use cases we should definetly take a decision on whether completion operations are useful and so should be leveraged or whether to use the executionEnded (or a kind of propagateToParent method as used in the lightning version) or even what about using the last one in both cases ?
regards,
Miguel Valdes -
3. Re: i'm refactoring child node execution a bit
tom.baeyens Aug 7, 2007 10:30 AM (in response to tom.baeyens)just committed the nested node execution refactoring.
i removed the completion operations and leveraged the list of ExecutionScope's for that.
SequenceTest and ConcurrentChildTest are working
i still have a few problems to chew on.
i had to remove the locking (the problem that charles had in the first place). in theory this should work. so i'll further investigate that.
also operations on different executions don't run in the same while loop of atomic operations. not sure if that is necessary. if we could do it, it would be better, but i don't see an easy way to do it. also, only in the Flow implementation of the ConcurrentChildExecution that would matter and that implementation shouldn't have side effects.
I'm happy with most of how the Flow implementation looks. Only the return values in the signal might be a bit unclear. -
4. Re: i'm refactoring child node execution a bit
tom.baeyens Aug 7, 2007 10:44 AM (in response to tom.baeyens)"mvaldes" wrote:
1.- Transitions based execution with child executions (simple splits and joins). We have already set up some test on that on the unit test called ChildExecutions.java
2.- Nested nodes executions with concurrent executions (i.e simple FLOW)
3.- Transitions based executions mixed with nested nodes (both simple and concurrency use cases). This use case was described here http://jboss.com/index.html?module=bb&op=viewtopic&t=115092
4.- Nested nodes executions with transitions inside. This is a tricky one, I don't know yet if useful (also described in the previous link)
5.- Nested node in the same path of execution + variant of this in which there is another node to the process to be executed (the one you proposed)
3 and 4 are not necessary i think.
probably it's the easiest if i just complete the initial test suite. then once the basics are running, we can further expand the test suite together.
we can work together on the list of basic tests that should be produced. here's my proposal for prioritization.
1) AutomaticActivityTest: 3 automatic nodes connected with transitions.
2) WaitStateTest: 3 wait state nodes connected with transitions.
3) SequenceTest:
* 3 automatic nodes nested in a sequence node.
* 3 wait state nodes nested in a sequence node.
4) Action test:
* node enter action
* node leave action
* transition action
5) Decision test
* automatic decision
* external decision during a wait state (signal corresponds to the transition that needs to be taken)
6) Concurrency
* nested node concurrency (3 concurrent nodes in one Flow)
- 3 concurrent automatic nodes in 1 flow
- 3 concurrent wait states in 1 flow
* transition based concurrency based on incoming transitions (bonita)
- 3 concurrent automatic nodes between a fork and a join
- 3 concurrent wait states between a fork and a join
* transition based concurrency based on execution sibblings (jpdl)
- 3 concurrent automatic nodes between a fork and a join
- 3 concurrent wait states between a fork and a join
concurrency variations:
- concurrency in a loop
- nested concurrency
1-4 are done. 5 is TODO but trivial. 6 is still to do.
what do you think of the prioritization in 6 ? am i missing a lot of basic scenarios ? -
5. Re: i'm refactoring child node execution a bit
mvaldes Aug 7, 2007 11:00 AM (in response to tom.baeyens)I agree those are the basics ones for the three initial targeted languages: XPDL, BPEL and JPDL
Some of the unit tests in 6 can also be adapted from the existing ones which leverages two nodes rather than three.
I still thinking that would be great to be able to mix nested and transitions based executions but I think we could postpone those ones.
Charles, something you want add there as a first unit tests series ?
regards,
Miguel Valdes -
6. Re: i'm refactoring child node execution a bit
csouillard Aug 7, 2007 11:17 AM (in response to tom.baeyens)Maybe we can add the following
1 flow with 3 children (c1, c2, c3)
c1 is a sequence having 2 children : 1 automatic and 1 waitState
c2 is a flow having 2 children : 1 automatic and 1 waitState
c3 is sequence having 1 child (c4)
c4 is a flow having 2 children : 1 automatic and 1 waitState
With this test we have most of the cases of concurrency.
Thoughts ?
Charles -
7. Re: i'm refactoring child node execution a bit
tom.baeyens Aug 7, 2007 11:32 AM (in response to tom.baeyens)after the initial basic testing, i would like to see a whole series of those kinds of combination tests.
preferrably with some sort of strategy on which combinations we'll test. the strategy on which combinations we'll make should partly be based on the knowledge of the implementation. as we can expect the weak points of our implementation. but partly, the combinations should be systematic.
we'll need good judgement in this. -
8. Re: i'm refactoring child node execution a bit
mvaldes Aug 13, 2007 11:08 AM (in response to tom.baeyens)"tom.baeyens@jboss.com" wrote:
1) AutomaticActivityTest: 3 automatic nodes connected with transitions.
2) WaitStateTest: 3 wait state nodes connected with transitions.
3) SequenceTest:
* 3 automatic nodes nested in a sequence node.
* 3 wait state nodes nested in a sequence node.
4) Action test:
* node enter action
* node leave action
* transition action
5) Decision test
* automatic decision
* external decision during a wait state (signal corresponds to the transition that needs to be taken)
6) Concurrency
* nested node concurrency (3 concurrent nodes in one Flow)
- 3 concurrent automatic nodes in 1 flow
- 3 concurrent wait states in 1 flow
* transition based concurrency based on incoming transitions (bonita)
- 3 concurrent automatic nodes between a fork and a join
- 3 concurrent wait states between a fork and a join
* transition based concurrency based on execution sibblings (jpdl)
- 3 concurrent automatic nodes between a fork and a join
- 3 concurrent wait states between a fork and a join
concurrency variations:
- concurrency in a loop
- nested concurrency
1-4 are done. 5 is TODO but trivial. 6 is still to do.
what do you think of the prioritization in 6 ? am i missing a lot of basic scenarios ?
Looking into this TODO list I noticed that most of those use cases are done, isn't it ?
If you are done with that, we would like to propose you to work (on our side) on the following ones:
- Nested concurrency (i.e nested flows)
- Adding/removing child executions (including updates in ExecutionImpl.java)
- Unstructured split-join behaviours based on incoming transitions
- Transition based with nested node concurrency (again I think that could be useful)
- Two phase execution for waitstates (the Bonita like's manual activities execution: start vs terminate operations)
- Anticipating execution
...
Thoughts ?
regards,
Miguel Valdes