12 Replies Latest reply on Jan 4, 2019 12:53 AM by akhilsoman123

    How to model 3 retries every 15 minutes on a custom task (temporary fail)?

    antonio.giambanco

      Hi all

      I'm wondering how to model a process with a custom task that perform for example 3 retries every 15 minutes and after that if I still get an exception I would like to log or write in a queue and stop the process, if it is just a temporary problem it follow its normal path.

       

      thanks

        • 1. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
          swiderski.maciej

          you could use error boundary events attached to service node and service node would throw an error in case of failure and then the handler would loop back to this service node after going via intermediate timer event. Use some process variable to handle retry count. You could use jbpm executor that handles retry automatically for you though it does not allow wait time between retries to be configured (feel free to file jira for this as it shall be easy to fix).

           

          HTH

          1 of 1 people found this helpful
          • 2. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
            animusib

            Hi Maciej,

             

            I am also facing this same issue. Is this already fixed? Currently the "RetryDelay" property is available for AsyncTask only. But, how do we use that for executor? Can we pass the parameter to context somehow for a ServiceTask, so that executor picks it up and uses for retries on error?

             

            Please let me know if you want me to file a jira for this?

             

            Thanks,

            Anindya

            • 3. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
              swiderski.maciej

              yes, it's done in 6.3.0.Final for configurable retry of failed executor jobs. Here some details:

               

              Implemented by providing additional parameter used for CommandContext data named

               

              retryDelay 

               

              It can be either set directly on CommandContext or via AsyncWorkItemHandler parameters. In case of work item parameters the name of the parameter should be

               

              RetryDelay 

               

              It's capitalized for the sake of consistency with other work item parameters used for AsyncWorkItemHandler.

              Retry delay can be given as:

              • single time expression - 5m or 2h or etc
              • comma separated list of time expressions that should be used for subsequent retries - 10s,10m,1h,1d

              In case number of retry delays is smaller than number of retries it will use last available value from the list of retry delays. Which for single value means it will always be the same value.

              • 4. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                animusib

                Hi Maciej,

                 

                Thanks for the detailed information. I am fine with this. But can I use the RetryDelay parameter in Service Tasks? I can just add a metaData to Service task (customAsync=true) and it will run asynchronously, but can I also set the parameter RetryDelay? From the source, it doesn't look like it will work. Can you please help on this?

                 

                Also, what happens when all the retries get used? Is there a way to handle the exception in a different way when all the retries are used up. Please advise on this.

                 

                Thanks,

                Anindya

                • 5. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                  animusib

                  Hi Maciej,

                   

                  I am able to successfully replace all the Service Task with AsyncWorkItemHandler. I have done this by extending ServiceTaskHandler and overriding the method executeJavaWorkItem() to invoke asyncWorkItemHandler's executeWorkItem() method. And also created a JavaCommand class to execute the method using reflections, similar to what is done by ServiceTaskHandler.

                   

                  This is working fine and every service task is now retrying automatically on error. To fine tune this, I think, I will also extend AsyncWorkItemHandler and setup a properties based retryDelay parameter, so that that can be applied in General. I can also now pass retryDelay from ServiceTask, which is read by asyncHandler.

                   

                  I want a suggestion on the exception part. When all the retries are used up, the process sits idle in PROCESSINSTANCEINFO table and the command request is shown as ERROR in the REQUESTINFO table. Afterwards, after fixing the error, I can programmatically retrieve this request object and reschedule the command using the Command Context from that request. This immediately resumes the process and completes as expected. But the old request with ERROR status remains as is. The problem is that, if I fetch all requests in ERROR status next time, it will fetch the completed ones also, which is not expected. I cannot fetch based on active process instance, because if I retry several times this way, I will end up with several ERROR requests, which will make it more difficult to choose a distinct request. And it will hit performance.

                   

                  Do you think, it would be better to write custom queries as the existing ones available under the RuntimeDataService, ProcessService etc are not sufficient and I cannot perform join using them.

                   

                  Please advise on this and also provide your feedback on the above approach.

                   

                  Thanks,

                  Anindya

                  • 6. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                    animusib

                    OK. I got the solution to this as well. Just used the executorStoreServices to update the Request to STATUS.RETRYING and it automatically retried once. The same request record got updated to DONE and increased the number of executions.

                     

                    Please give feedback to the entire approach.

                     

                    Thanks,

                    Anindya

                    • 7. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                      swiderski.maciej

                      instead of using ExecutorStoreService you can cast ExecutorService to RequeueAware (jbpm/RequeueAware.java at master · droolsjbpm/jbpm · GitHub) and then simply call requeue with given request id which will put it back to queued so it will be executed again.

                       

                      the approach seems ok, if I understood it right, you did that mainly to not change your process definition that was already suing service tasks - replace service tasks with async task.

                       

                      Good job!

                      • 8. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                        animusib

                        Thanks Maciej.

                         

                        Yes you guessed it right. We are in a situation of having 200+ service tasks in around 50+ processes and it keeps growing. So I found this way easier to replace them all

                         

                        I will definitely try using RequeueAware to make it more aligned with the framework.

                         

                        Thanks a lot for giving me confidence. I am enjoying working with jBPM and looking forward for future versions with more features

                        • 9. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                          animusib

                          Hi Maciej,

                           

                          The RequeueAware casting worked like a charm. Thanks for the tip.

                           

                          I have one more question for this topic. When I abort any process instance using processService.abortProcessInstance() method, it removes the corresponding records from both PROCESSINSTANCEINFO and WORKITEMINFO tables. But the record in REQUESTINFO still remains as is in ERROR status. Is this a bug? Due to this, I have to manually filter out the requests whose processInstance has a STATE > 1, so that I get a correct list of requests which can be retried.

                           

                          Please advise if there are any alternatives to this. If needed I can file a Jira for this.

                           

                          Thanks,

                          Anindya

                          • 10. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                            swiderski.maciej

                            that's done on purpose as jobs are more generic and thus are not automatically removed. You can configure another job that will do the proper cleanup based on your needs, see this: Keep your jBPM environment healthy

                             

                            HTH

                            • 11. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                              animusib

                              Thanks Maciej. I have already configured Audit Cleanup job. So all set for this

                              • 12. Re: How to model 3 retries every 15 minutes on a custom task (temporary fail)?
                                akhilsoman123

                                Hi Maciej,

                                 

                                i also having the same kind of problem. i need to model a business process in which every workitem handler should have the capability of retrying the task as well as pausing the process flow in between for some events to happen and the continue the flow. if the task fails in a node, i should have the option to either retry the task or skip that task and continue the remaining flow. and this should happen by triggering a signal.  how can i achieve this? i have gone through the discussion between you and Anindya on the same topic where you discussed about executor. since i'm a newbie in jbpm, i'm not aware of how to implement this using executor. could you please suggest a way to achieve my requirement.

                                 

                                Thanks in advance