[JBoss jBPM] - Re: Action not executing in timer
by oravecz
I go to sleep in my unit test. I have to give the timer a chance to do its thing. I suppose I could add a listener to some transition events but they would only fire if everything is working correctly. Defeats the purpose of the unit test.
If you are saying that I have to manually close a context in order to flush/commit, I would say that's a very bad design. Sure, while I am in my unit test I have the option of calling context.close(), a longer running process with various wait states does not have that luxury. It has to be handled internally by the engine in these cases.
anonymous wrote :
| but in normal cases you do not keep it open and a process goes in a waitstate. You only open it again if e.g. an external system or person acts on something. ... In most cases there only is one real thread of execution. Sure, you can have parallel things in forks, but they seldom act on the same thing at the same time. There are some things being looked into regarding locks/transactions and a join (see the jira)
|
Yes, and the JobExecutor is this external system that acts on something. Any time you are using timers, you have multiple threads of execution. Therefore the engine must have some means of flushing & commit when a timer is created, but it looks to me that it has to be done manually.
I will open a Jira if you can confirm that some automatic commit/flush does not exist.
BTW, here is my unit test. It works now as long as I commit manually from the main thread. I get the lock exception if I do not.
| @Test
| public void test() {
| // Create an instance of the order workflow process
| JbpmContext context = _jbpmConfiguration.createJbpmContext();
| final GraphSession graphSession = context.getGraphSession();
| final ProcessDefinition process = graphSession.findLatestProcessDefinition("examplePause");
| ProcessInstance processInstance = process.createProcessInstance();
|
| // Kick off the process
| Token token = processInstance.getRootToken();
| token.signal();
|
| Assert.assertEquals(token.getNode().getName(), "state1");
|
| // Force the timer task to be committed (Note: this is where I don't understand
| // why this is a manual step. If this was running outside of a unit test,
| // Where would this commit go?
| context.close();
|
| // Sleep. Timer should fire within 10 seconds. At wakeup, we should be in the end node.
| try {
| Thread.sleep(15000);
| } catch (InterruptedException e) {
| e.printStackTrace();
| }
|
| // note the need to recreate the context and refetch the token...
| context = _jbpmConfiguration.createJbpmContext();
| token = context.getToken(token.getId());
|
| Assert.assertEquals(token.getNode().getName(), "endPauseExample");
| }
|
Thanks Ronald for your assistance throughout this process. Seems like you are a one-man show. :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181727#4181727
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181727
17 years, 5 months
[JBoss jBPM] - Re: Action not executing in timer
by kukeltje
anonymous wrote : By adding a context.close() call before I go to sleep
??? You go to sleep? like in a thread? Wrong usage.
anonymous wrote : Is this a bug or an accepted workaround?
Neither, it is how you *should* do things.
anonymous wrote : I will now have to reopen it again to lookup a process definition or other such tasks.
Correct.. but in normal cases you do not keep it open and a process goes in a waitstate. You only open it again if e.g. an external system or person acts on something.
anonymous wrote : but that strategy falls apart when there are other threads of execution (ala JobExecutor, custom web service, etc.) that is needing to update the database.
|
In most cases there only is one real thread of execution. Sure, you can have parallel things in forks, but they seldom act on the same thing at the same time. There are some things being looked into regarding locks/transactions and a join (see the jira)
anonymous wrote : In fact, the main thread only issues one commit when the process definition is inserted into the database at startup.
Show us your unittest... might be 'wrong' usage in there
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181725#4181725
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181725
17 years, 5 months