Hi All,
I am trying Flowable for the first time. I am hitting certain roadblocks and would love to get inputs from the more seasoned ones here.
For now I am just adding them manually ion the xml.
2. But the job is retrying endlessly and is not respecting the retry of 2.
What am I doing wrong?
Hey @sukalpo,
What kind of an extension element are you talking about? Is it for a timer, or is it something else?
Can you provide is with a Minimal working example that would show this problem? Or at least share the BPMN XML that has this problem?
Thanks,
Filip
Hi @filiphr , Thanks for the reply.
I am sharing the xml below. The extension that I am telling about is to add the flowable:failedJobRetryTimeCycle that is in the xml.
Also attaching the Java Delegate. So the main objective is to throw a runtime exception. And when the retry count reaches a threshold to throw a BPMNError. I am expecting the boundary error event will catch this event and then process will flow to the LogErrorTask which is also not happening. Thanks in advance.
public class GetClaimablePoliciesTask implements JavaDelegate {
public static int retry = 0;
private static final Logger LOG = LoggerFactory.getLogger(GetClaimablePoliciesTask.class);
@Override
public void execute(DelegateExecution delegateExecution) {
retry++;
LOG.info("Retry count:- " + retry);
if (retry != 4) {
throw new RetryableException();
} else {
throw new BpmnError("mail");
}
}
}
@filiphr I found out the solution for sending the error event. I am just stuck with the retry. As mentioned How to add the extension element through modeller and then why the retry is getting triggered infinitely
@sukalpo it looks like the flowable:failedJobRetryTimeCycle property is not exposed in the web modeler.
For the retry. How are you tracking the retry count? Is it that with the GetClaimablePoliciesTask or do you have some other way to track it?
If you are doing it like with your example code then the retry count should work as it is a static variable. However, that would only work once after a startup of the server (due to the static)
Thanks @filiphr, For a poc I am using a static variable. However in the actual code, I plan to save the rety count in DB and when it exceeds a certain value I am going to throw a BPMN error. But wont flowable only retry the time that is mentioned in the expression “R2/PT1” which is 2 times. But I am seeing if I dont give the expression then flowable retries 3 times. But if I give it keeps on retrying every time I throw a runtime exception
In order to do this you will have to save this in a special way. If you don’t do something special with a new transaction then your save would just be rollbacked (due to the exception being thrown).
If you don’t set that expression then Flowable would retry by default 3 times (this is configurable in the process engine configuration). When you set the failedJobRetryTimeCycle then it should use that, so in your case 2 times. After the job has run through all the retries it will go to the dead letter jobs.
Just checked the code if there is no exception message then the retried from failedJobRetryTimeCycle will always be used. Can you try adding a message to your runtime exception?
Having said all of this if you need to throw a BPMN error after certain number of retries you would need to model this in your process. Instead of throwing a runtime exception you would need to throw one kind of BPMN error, then when that error occurs go back to the service task, after your retry count is done you would need to throw your other BPMN error.
To me right now it seems like the retry count has some business logic into it, and you are trying to use the Flowable Job retries to model that.
Cheers,
Filip
Thanks @filiphr, I will try the runtime error suggestion and let you know the outcome
Hi @filiphr the above suggestion worked thanks.
Thanks for the above pointer too. I was confused about the rollback when I re-read this comment of yours. I am now saving it through a new transaction.
@filiphr I added
flowable:failedJobRetryTimeCycleR6/PT1M</flowable:failedJobRetryTimeCycle>
and I am throwing an exception – RuntimeException(“retry”); but this configuratiuon is not picked up. It just retries 3 times with a delay of 20 secs
Any idea what I am doing wrong?
@filiphr I resolved the issue by setting the number of retries and retry wait time through process configuration engine. Though it would be nice to know why the failedJobRetryTimeCycle is not picked up as it will give me an avenue to configure per service task
Hi filiphr,
I have service tasks and its working good. But the retry is not working after I moved from h2 database to Oracle. Could you please suggest, is there any config that I need to check with Oracle.
Thanks
Jose