1) there is a real persisted wait state (and its set from one minute to 19 days depending on the action taken by the user) but we have been getting stack overflow errors (after running 24/7 for about 2 weeks) and then timers stop working (we have to restart the application server) and this is considered the culprit. Given this, one of our developers doesn't want to use jBPM for batch processing that would require escalation (via a timer) every minute. I however would like to use jBPM because then we could leverage jBPM to create fail/retry logic with nodes and the jBPM console for visibility into the batch processing. (and yes there probably are alternatives to using the same token over in a loop but again thats why this was titled design patterns).

2) In the second part, in its simplest, its a task node to a fork with one transition from the fork going back to the task node and a second transition from the fork going to a different task node. When done manually from the first task node (user signals the transition rather then some external event or a timer) its an easy way to allow for a "Resend" A simple example would be "Supervisory Approval" where tokens comes into a "Processor" task node wHere they transition the token to "Supervisor Approval" but still want the token to remain in their task node in parallel, having the "send for approval" transition go to a fork solves this easily, the token goes back to the "Processor" task node and then also goes to the "Superviosr Approval" task node (with a join at the end of all of this of course). The processor continues to have it as an active task and so does the supervisor, then if the processor has an additional task that needs to be done by the supervisor (but again wants to continue to have the task as well) they simply transition the token to the supervisor task node again. In testing this all works perfectly, and all of the child tokens complete out of the join properly but it does seem that there is a limit to the number of inherited children (like maybe 1000) so if the transitions are manual no problem but if automated with timer then its a problem. The question was asked because there is concern that some "idiot" might want to click the button 1000 times an therefore cause stack overflow to occur, we can put a check in to limit this to something reasonable like 10 times but maybe we shouldn't do this at all...

P.S. sorry about posting initially to the wrong forum.

1) The log file could be a problem... thanks
2) the token does reach the join and continues on through (we though the same thing but upon testing and looking at what the database did, it worked)

3) there are two functional requirements:

a) I'll skip the batch processing functional requirements because at this point they are vague. (Basically processing as files are uploaded into a directory or when a record in an external database is updated, etc. and probably the challenge here is more in deciding to write a custom action or a custom node... or because logging could get out of control don't do it in jBPM.

b) User has a task but supervisor should also get a task every day task sits in processors list of tasks. All tasks as related to the initial task from a reporting standpoint.