"emp.tyres" wrote : Thanks for the replies - 
  | 
  | "kukeltje" wrote : 1: Exception handling like in jBPM 3 is still on the 
todo list (look in Jira). 
  | 
  | Actually, I was more trying to understand what options are there to recover 
the process after an UNhandled exception - assuming a job fails due to an 
automatic action throwing an exception, what state will it end in, and how can 
we recover it (change the offending variable, restart the failed activity, 
etc.)? I understand this is not trivial, but it is still very important for us 
as we are orchestrating a large number of systems on a critical process. 
  | 
That is precisely what the jBPM 3 exceptionhandler was (partly) for. Doing 
'some things', restarting the activity not being one of them, but if you use 
async for this, the job is rolled back and retried. Normally, 'changing the 
offending variable' would /could be done in an adition actionhandler e.g. on 
the transition that is taken in case of an error. The error has to be caught 
then in the actionhandler and the 'error transition' name has to be returned.

"emp.tyres" wrote :  
  | "kukeltje" wrote : For technical retries to external systems etc, I do not 
think jBPM should reinvent (reimplement) the wheel  (like they are doing in 
drools with reinventing workflow) but leverage what is already there, JBoss ESB 
or JMS or your custom code/custom node. For business level retries, what you 
describe is an option. Might require a custom node though. 
  | 
  | Agreed - I am a bit worried at implementing a wait / loop / wait / loop 
custom node, though (e.g: is now after given date? if so, proceed, alse 
thread.sleep(10000) and then re-enter activity through self-looping 
transaction) - I tried it and it technically works, but does it risk hanging 
the whole PVM?
  | 
Yes as it can result in thread starvation

"emp.tyres" wrote :  
  | And would it behave correctly with persistence assuming e.g. JBoss is 
restarted? [I can provide the code if you think it could be useful for a test 
case]
  | Not fullly, because it might be in a transaction and you could have had 
multiple retries already that get lost.

"emp.tyres" wrote :  
  | [BTW, this was triggered by "duedatetime" in timers throwing a 
org.jbpm.api.JbpmException: no 'jbpm.duedatetime.format' in current 
environment, adding the string to the jbpm.cfg.xml does not solve it - I could 
not find any JIRA for it - anyone had any success in using duedatetime?]

In 4? I myself not, but I've seen posts in the forum of people that have 
successfully used it.

View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253302#4253302

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253302
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to