The command executor thread is taking care of asynchronous command execution.
In the starter kit this one (and the scheduler thread) are created by the JbpmThreadsServlet in the web-app.
This means in order to have asynchronous command execution (or scheduler) you need to deploy the web-app.
Another option is to put the code which starts those two threads somewhere else (in case you really don't use the web-app).
Are you sure the command execution thread is running?
I had redeployed the webapp, but that did not seem to make a difference. Turns out there was an error occuring on startup of the webapp; trying to insert a value too large for the DB. Since we don't really want the webapp, I just added the CommandExecutorThread.start() to our own app's initialization code, and all seems to be working well again.
Yeah, I started seeing this same problem. Once you get the SQL error, async stops working completely. I believe somewhere in the chain of errors you will see a message saying that the command executor thread has stopped. I didn't really connect the dots on that until after reading this though. The problem I believe I was having is that if an error occurs in a delegation class, jbpm wants to stick the stack trace into the jbpm_message table. Well, most stack traces are pretty large, and it was causing the SQL error for me every time. Furthermore, the jbpm_message table entry would never get removed. So when I would restart the server, the process would run again and cause the same SQL error. I kind of fixed the problem by commenting out the part in the jbpm code where it sets the error stack trace into the jbpm_message entry. That prevented it at least from breaking async for good when an error occurs.