Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Timeout Handler not working in AEM 6.4.2

manishprabhut20
Level 1
Level 1

We have a custom workflow for Activate Later in AEM 6.4.2 which is migrated from AEM 5.6.1 which have the below steps:

1. Create Version- The version is created succesfully

2. Participant Chooser Step: Wait for activation assigned to admin user and have the timeout settings value are as follows:

a. Timeout Handler: Absolute Time Auto Advancer

b. Timeout: Immediate

3. Activate

 

The workflow is stuck in step 2 and is throwing the below warning in the log-

-Granite Workflow Timeout Queue(com/adobe/granite/workflow/timeout/job)] com.adobe.granite.workflow.core.job.TimeoutHandler WorkItem does not exist: /var/workflow/instances/server0/2020-01-13

 

Even if the workitem node exists in the path mentioned.

We tried giving the permissions to workflow-service user and workflow-process-service user but the same error is coming.

 

Please provide some suggestions.

3 Replies
Vijayalakshmi_S
Community Advisor
Community Advisor

HI,

 

The error says that process for "Timeout Handler"  does not exist.  Check for the status of the TimeoutHandler OSGI component in felix console. 

Also check if it is the case with new workflow as well.

  • Create a new sample workflow model in 6.4.2 instance
  • Configure participant/process step and hence define TimeoutHandler as "Absolute Time Auto Advancer".
  • Sync the changes and test the workflow.I

 

Vijayalakshmi_S
Community Advisor
Community Advisor

Check the status of Absolute Time Auto Advancer as well (com.day.cq.workflow.timeout.autoadvance.AbsoluteTimeAutoAdvancer or com.adobe.granite.workflow.console.timeout.autoadvance.AbsoluteTimeAutoAdvancer) which ever you have associated. 

manishprabhut20
Level 1
Level 1

Providing administrators group to the workflow-process-service and workflow-service resolved the same. If we happen to not provide to any one of the the above user it failed.