AEM Workflow Debugging — 6.5 LTS / AMS
Production-grade debugging for AEM Granite Workflow engine, launcher, Inbox, Sling Jobs, thread pools, and purge on AEM 6.5 LTS and Adobe Managed Services (AMS).
Variant Scope
- This skill is 6.5-lts-only (includes AMS).
- Full JMX access via Felix Console or JMX client.
- Config changes via Felix Console or OSGi config in repository.
When to use this skill
- Workflow stuck, not progressing, failed, not starting, task not in Inbox, purge/repository bloat, permissions, queue backlog, thread pool exhaustion, auto-advancement not working.
- User provides thread dumps, configuration status ZIPs, Sling Job console output, or error.log excerpts.
- Environment: AEM 6.5 LTS / AMS (JMX available).
Step 1: Map symptom to first action
| Symptom |
symptom_id |
First action |
| Workflow stuck (not advancing) |
workflow_stuck_not_progressing |
Open instance; note current step type. No work item → stale. |
| Task not in Inbox |
task_not_in_inbox |
Confirm Participant step; assignee = logged-in user; Inbox filters. |
| Workflow not starting (launcher) |
workflow_not_starting_launcher |
Launcher enabled; path/event match payload. |
| Workflow fails or shows error |
workflow_fails_or_shows_error |
Instance history; error.log for instance ID; payload and process. |
| Step failed, retries exhausted |
step_failed_retries_exhausted |
Logs → process.label → JMX retryFailedWorkItems or Inbox retry. |
| Stale (no current work item) |
stale_workflow_no_work_item |
JMX countStaleWorkflows → restartStaleWorkflows(dryRun=true). |
| Repository bloat / too many instances |
repository_bloat_too_many_instances |
JMX purgeCompleted(dryRun=true) or Purge Scheduler. |
| User cannot see or complete item |
user_cannot_see_or_complete_item |
Assignee/initiator/superuser; enforce flags. |
| Cannot delete model |
cannot_delete_model |
JMX countRunningWorkflows → terminate → delete. |
| Slow throughput / queue backlog |
slow_throughput_queue_backlog |
JMX returnSystemJobInfo; queue.maxparallel on Granite Workflow Queue; Sling thread pool. |
| Auto-advancement not working |
workflow_auto_advance_failure |
Check default thread pool saturation; Sling Scheduler; timeout jobs. |
| New workflow not working |
workflow_setup_validation |
Model sync, launcher, process registration, permissions. |
Step 2: Decision tree (workflow stuck)
- No current work item? → Stale. JMX:
countStaleWorkflows → restartStaleWorkflows(dryRun=true).
- Participant step → Assignee exists? Inbox visible? Payload accessible? Dynamic participant resolver returning correct user?
- Process step → Search error.log for instance ID. Check:
process.label registered, payload path exists, bundle active, no exception in execute().
- OR/AND Split → Condition evaluates correctly? Routes exist? No dead-end branches? Model synced?
Step 3: Thread dump & thread pool analysis
Thread dumps on 6.5 / AMS are obtained via jstack or by requesting from AMS support. Configuration status ZIPs from Felix Console → Status → Configuration Status.
3a. Sling default thread pool (critical path)
The Sling Scheduler ApacheSlingdefault uses ThreadPool: default. This pool runs:
- Oak observation events
- All Quartz-scheduled jobs — including the workflow timeout-detection scheduler that emits
com/adobe/granite/workflow/timeout/job events to the Sling Job system (the job itself then runs on the Granite Workflow Queue, see Step 3c)
Check the Sling Thread Pools status page (/system/console/status-slingthreadpools):
| Field |
Healthy |
Problem |
| active count |
< max pool size |
= max pool size (saturated) |
| block policy |
RUN |
ABORT (rejects tasks when full) |
| max pool size |
sized for workload |
OOTB on AEM 6.5 LTS is 5/5 (Apache Sling default). Bump to 20+ in OSGi config for environments with many custom periodic schedulers, otherwise schedulers can starve. |
If active count = max pool size AND block policy = ABORT:
- New scheduled tasks (including workflow timeout/auto-advance jobs) are silently rejected
- This is the #1 cause of auto-advancement failure
Check the Threads status page (/system/console/status-Threads) or the jstack thread dump (/system/console/status-jstack-threaddump):
- Search for
sling-default- threads
- If all threads show same stack (e.g. stuck on HTTP call, database, or external service), that's the blocking culprit
- Note
elapsed time — threads stuck for hours indicate a hung external call without timeout
3b. Sling Job thread pool
Check Apache Sling Job Thread Pool in the Sling Thread Pools status page:
- active count vs max pool size
- If saturated, Sling Jobs cannot execute (workflow jobs stall)
3c. Granite Workflow Queue
Check the Sling Jobs page (/system/console/slingevent):
| Field |
Healthy |
Problem |
| Queued Jobs (overall) |
0 |
> 0 (jobs waiting) |
| Failed Jobs |
0 |
> 0 (step failures) |
| Active Jobs |
0-N |
0 when Queued > 0 (jobs not picked up) |
Check topic statistics for workflow model:
- Topic:
com/adobe/granite/workflow/job/var/workflow/models/<modelName>
- High
Failed Jobs / low Finished Jobs ratio → process step throwing exceptions
Check Granite Workflow Queue configuration:
- Type: Topic Round Robin
- Max Parallel: 0.5 OOTB on AEM 6.5 LTS (50% of available CPU cores). Increase for throughput on bursty workloads. Verify the running value at
/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration~workflow before assuming.
- Max Retries: 10
3d. Sling Scheduler
Check the Sling Scheduler status page (/system/console/status-slingscheduler):
- This page lists Quartz-style schedulers, not Sling Job topics. On OOTB AEM 6.5 LTS the workflow-related entry visible here is the periodic
WorkflowStatsMBean collector (used by the Statistics MBean) — its nextFireTime should be in the near future; nextFireTime: null means the trigger was deregistered.
- The
com/adobe/granite/workflow/timeout/job topic itself is a Sling Job, not a Quartz job — check it on the Sling Jobs page (/system/console/slingevent), not here.
- Confirm
ApacheSlingdefault uses ThreadPool: default — that's how the periodic timeout-detection scheduler reaches the workflow engine.
Step 4: Error log patterns
| Pattern |
Cause |
Action |
Error executing workflow step |
Process step exception |
Check stack; fix process code or payload |
getProcess for '<name>' failed |
No WorkflowProcess registered |
Deploy bundle; match process.label |
Cannot archive workitem |
Archive failure → stale risk |
JMX restartStaleWorkflows |
refreshing the session since we had to wait for a lock |
Lock contention |
Tune queue.maxparallel on the Granite Workflow Queue (Apache Sling Job Queue Configuration); reduce concurrent writes to the same path |
Terminate failed / Resume failed / Suspend failed |
Permissions (not initiator/superuser) |
Check enforceWorkflowInitiatorPermissions; add to superusers |
PathNotFoundException (workflow/payload) |
Payload/launcher path missing |
Verify payload exists; check launcher config path |
Error adding launcher config |
Launcher config path not created |
Create /conf/global/settings/workflow/launcher/config |
retrys exceeded - remove isTransient |
Transient workflow failed after retries |
Fix process code; instance persisted for admin handling |
RejectedExecutionException |
Thread pool full with ABORT policy |
Increase pool size or change policy to RUN; fix stuck threads |
Workflow is already finished |
Terminate on completed/aborted instance |
Check logic calling terminate |
Workflow purge '<name>' : repository exception |
Purge JCR error |
Check permissions; repo health |
Step 5: Configuration checklist
In Felix Console → OSGi → Configuration (/system/console/configMgr):
| Config |
Property |
Check |
| WorkflowSessionFactory |
cq.workflow.job.retry |
Default 3; increase for flaky steps |
| WorkflowSessionFactory |
cq.workflow.superuser |
Must include admin users/groups (OOTB list includes admin, administrators, workflow-process-service, workflow-service, workflow-administrators, wcm-workflow-service) |
| WorkflowSessionFactory |
granite.workflow.enforceWorkitemAssigneePermissions |
true (OOTB) = only assignee sees items |
| WorkflowSessionFactory |
granite.workflow.enforceWorkflowInitiatorPermissions |
true (OOTB) = only initiator (or superuser) can terminate/suspend/resume |
| WorkflowSessionFactory |
granite.workflow.inboxQuerySize |
Max work items returned per Inbox query. OOTB 2000; raise if heavy users hit the cap |
| WorkflowSessionFactory |
granite.workflow.maxPurgeSaveThreshold |
OOTB 20 — commit after this many purged instances. Raise carefully to reduce JCR overhead during large purges |
| WorkflowSessionFactory |
granite.workflow.maxPurgeQueryCount |
OOTB 1000 — JCR query batch size during purge. Tune with above |
Granite Workflow Queue (org.apache.sling.event.jobs.QueueConfiguration~workflow) |
queue.maxparallel |
Real parallelism knob. OOTB on AEM 6.5 LTS is 0.5 (50% of CPU cores). Adobe's Workflows Best Practices recommends between half and three-quarters of processor cores. cq.workflow.job.max.procs displayed in Felix Config Manager is an orphaned metatype label with no code path that reads it (verified against source on release/660 and prod/cq660) — do not rely on it. Verify the running value at /system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration~workflow |
DefaultThreadPool (name=default) |
block policy |
OOTB RUN. ABORT would silently drop workflow timeout jobs — keep RUN unless you have a specific reason |
DefaultThreadPool (name=default) |
max pool size |
OOTB on AEM 6.5 LTS is 5 (Apache Sling default). Bump to 20+ for environments with many custom periodic schedulers; otherwise the pool can starve under load |
Purge Scheduler (com.adobe.granite.workflow.purge.Scheduler) |
scheduledpurge.daysold |
30 default; tune per environment. Factory PID — deploy one config per schedule |
| Purge Scheduler |
scheduledpurge.workflowStatus |
Array-typed; e.g. ["COMPLETED"] |
Step 6: Remediation quick reference
| Action |
6.5 LTS / AMS approach |
| Retry failed work item |
JMX retryFailedWorkItems or Inbox Retry |
| Restart stale workflows |
JMX restartStaleWorkflows(dryRun=true) then execute |
| Purge completed |
JMX purgeCompleted(dryRun=true) or Purge Scheduler |
| Increase parallelism |
Felix Console: queue.maxparallel on the Granite Workflow Queue (Apache Sling Job Queue Configuration); or OSGi config in repo |
| Fix thread pool exhaustion |
Restart instance (immediate); fix stuck scheduler code; change block policy to RUN |
| Fix process not found |
Deploy bundle; process.label must match; Sync model |
| Fix auto-advancement |
Verify default pool not saturated; timeout jobs scheduled; block policy = RUN |
Step 7: Key JMX MBeans
All workflow maintenance and diagnostic operations live on a single MBean: com.adobe.granite.workflow:type=Maintenance. A separate MBean — com.adobe.granite.workflow:type=Statistics — exposes time-series workflow execution metrics for trend analysis.
| MBean |
Operations |
Purpose |
com.adobe.granite.workflow:type=Maintenance |
purgeCompleted(model [optional], days, dryRun), purgeActive(model [optional], days, dryRun), countRunningWorkflows(model [optional]), countCompletedWorkflows(model [optional]), countStaleWorkflows(model [optional]), restartStaleWorkflows(model [optional], dryRun), retryFailedWorkItems(dryRun, model [optional]), terminateFailedInstances(restart, dryRun, model [optional]), returnSystemJobInfo(), returnWorkflowQueueInfo(), returnWorkflowJobTopicInfo(), returnFailedWorkflowCount(model [optional]), returnFailedWorkflowCountPerModel(), listRunningWorkflowsPerModel(), listCompletedWorkflowsPerModel(), fetchModelList() |
Purge, stale detection/restart, retry failed items, bulk terminate, queue/job diagnostics, per-model counts and enumeration |
com.adobe.granite.workflow:type=Statistics |
getResults, clearRecords; plus get/set accessors for DataLifeTime, DataFidelityTime, DataProcessRate, DataRate |
Time-series workflow execution statistics |
Always use dryRun=true first before executing destructive purge or retry operations.
Step 8: Common root cause patterns (from real incidents)
Pattern A: Thread pool starvation → auto-advance failure
Symptom: Workflow auto-advancement stops; timeout jobs not firing; workflows stuck at participant step despite timeout configured.
Root cause chain:
- Custom scheduler (e.g.
AccessTokenScheduler) makes blocking HTTP call without timeout
concurrent = true allows overlapping executions on each cron trigger- Each stuck execution consumes a
default pool thread indefinitely
- All pool threads consumed (OOTB on AEM 6.5 LTS that's only 5; environments hardened for throughput typically run with 20+) → pool saturated
- If block policy has been changed to
ABORT (OOTB is RUN), new Quartz triggers are rejected silently; on RUN they instead pile up on the caller thread and back-pressure the dispatch
- The workflow timeout-detection scheduler cannot dispatch new
com/adobe/granite/workflow/timeout/job events
- Auto-advancement never happens
Diagnosis checklist:
Fix: Restart instance (immediate); fix scheduler code (add HTTP timeout, set concurrent=false); change pool policy to RUN; increase pool size.
Pattern B: High workflow job failure rate
Symptom: numberOfFailedJobs >> numberOfFinishedJobs for a workflow topic.
Root cause: Process step exception, payload deleted, or process not registered.
Diagnosis: Search error.log for Error executing workflow step + model name. Check process.label in Felix Console → OSGi Components.
Pattern C: Stale workflows accumulating
Symptom: Workflows in RUNNING state but no work items; Inbox empty despite running instances.
Root cause: Cannot archive workitem during transition; JCR session crash during step completion.
Diagnosis: Search for Cannot archive workitem; JMX countStaleWorkflows; restartStaleWorkflows(dryRun=true).
References
- For runbook locations: see reference.md
1---2name: workflow-debugging3description: Debug AEM Workflow issues on AEM 6.5 LTS and AMS including stuck workflows, failed steps, missing Inbox tasks, launcher failures, stale instances, thread pool exhaustion, queue backlogs, purge failures, and permissions errors.4license: Apache-2.05---67# AEM Workflow Debugging — 6.5 LTS / AMS89Production-grade debugging for AEM Granite Workflow engine, launcher, Inbox, Sling Jobs, thread pools, and purge on **AEM 6.5 LTS** and **Adobe Managed Services (AMS)**.1011## Variant Scope1213- This skill is **6.5-lts-only** (includes AMS).14- Full JMX access via Felix Console or JMX client.15- Config changes via Felix Console or OSGi config in repository.1617---1819## When to use this skill2021- Workflow stuck, not progressing, failed, not starting, task not in Inbox, purge/repository bloat, permissions, queue backlog, thread pool exhaustion, auto-advancement not working.22- User provides thread dumps, configuration status ZIPs, Sling Job console output, or error.log excerpts.23- Environment: AEM 6.5 LTS / AMS (JMX available).2425---2627## Step 1: Map symptom to first action2829| Symptom | symptom_id | First action |30|---------|------------|--------------|31| Workflow stuck (not advancing) | workflow_stuck_not_progressing | Open instance; note current step type. No work item → stale. |32| Task not in Inbox | task_not_in_inbox | Confirm Participant step; assignee = logged-in user; Inbox filters. |33| Workflow not starting (launcher) | workflow_not_starting_launcher | Launcher enabled; path/event match payload. |34| Workflow fails or shows error | workflow_fails_or_shows_error | Instance history; error.log for instance ID; payload and process. |35| Step failed, retries exhausted | step_failed_retries_exhausted | Logs → process.label → JMX `retryFailedWorkItems` or Inbox retry. |36| Stale (no current work item) | stale_workflow_no_work_item | JMX `countStaleWorkflows` → `restartStaleWorkflows(dryRun=true)`. |37| Repository bloat / too many instances | repository_bloat_too_many_instances | JMX `purgeCompleted(dryRun=true)` or Purge Scheduler. |38| User cannot see or complete item | user_cannot_see_or_complete_item | Assignee/initiator/superuser; enforce flags. |39| Cannot delete model | cannot_delete_model | JMX `countRunningWorkflows` → terminate → delete. |40| Slow throughput / queue backlog | slow_throughput_queue_backlog | JMX `returnSystemJobInfo`; `queue.maxparallel` on Granite Workflow Queue; Sling thread pool. |41| Auto-advancement not working | workflow_auto_advance_failure | Check `default` thread pool saturation; Sling Scheduler; timeout jobs. |42| New workflow not working | workflow_setup_validation | Model sync, launcher, process registration, permissions. |4344---4546## Step 2: Decision tree (workflow stuck)47481. **No current work item?** → Stale. JMX: `countStaleWorkflows` → `restartStaleWorkflows(dryRun=true)`.492. **Participant step** → Assignee exists? Inbox visible? Payload accessible? Dynamic participant resolver returning correct user?503. **Process step** → Search error.log for instance ID. Check: `process.label` registered, payload path exists, bundle active, no exception in `execute()`.514. **OR/AND Split** → Condition evaluates correctly? Routes exist? No dead-end branches? Model synced?5253---5455## Step 3: Thread dump & thread pool analysis5657Thread dumps on 6.5 / AMS are obtained via **jstack** or by requesting from AMS support. Configuration status ZIPs from **Felix Console → Status → Configuration Status**.5859### 3a. Sling `default` thread pool (critical path)6061The Sling Scheduler `ApacheSlingdefault` uses `ThreadPool: default`. This pool runs:62- Oak observation events63- All Quartz-scheduled jobs — including the workflow timeout-detection scheduler that emits `com/adobe/granite/workflow/timeout/job` events to the Sling Job system (the job itself then runs on the Granite Workflow Queue, see Step 3c)6465**Check the Sling Thread Pools status page (`/system/console/status-slingthreadpools`):**6667| Field | Healthy | Problem |68|-------|---------|---------|69| active count | < max pool size | **= max pool size** (saturated) |70| block policy | RUN | **ABORT** (rejects tasks when full) |71| max pool size | sized for workload | OOTB on AEM 6.5 LTS is **5/5** (Apache Sling default). Bump to 20+ in OSGi config for environments with many custom periodic schedulers, otherwise schedulers can starve. |7273**If active count = max pool size AND block policy = ABORT:**74- New scheduled tasks (including workflow timeout/auto-advance jobs) are **silently rejected**75- This is the #1 cause of auto-advancement failure7677**Check the Threads status page (`/system/console/status-Threads`) or the jstack thread dump (`/system/console/status-jstack-threaddump`):**78- Search for `sling-default-` threads79- If all threads show same stack (e.g. stuck on HTTP call, database, or external service), that's the blocking culprit80- Note `elapsed` time — threads stuck for hours indicate a hung external call without timeout8182### 3b. Sling Job thread pool8384**Check `Apache Sling Job Thread Pool`** in the Sling Thread Pools status page:85- active count vs max pool size86- If saturated, Sling Jobs cannot execute (workflow jobs stall)8788### 3c. Granite Workflow Queue8990**Check the Sling Jobs page (`/system/console/slingevent`):**9192| Field | Healthy | Problem |93|-------|---------|---------|94| Queued Jobs (overall) | 0 | > 0 (jobs waiting) |95| Failed Jobs | 0 | > 0 (step failures) |96| Active Jobs | 0-N | 0 when Queued > 0 (jobs not picked up) |9798**Check topic statistics for workflow model:**99- Topic: `com/adobe/granite/workflow/job/var/workflow/models/<modelName>`100- High `Failed Jobs` / low `Finished Jobs` ratio → process step throwing exceptions101102**Check Granite Workflow Queue configuration:**103- Type: Topic Round Robin104- Max Parallel: 0.5 OOTB on AEM 6.5 LTS (50% of available CPU cores). Increase for throughput on bursty workloads. Verify the running value at `/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration~workflow` before assuming.105- Max Retries: 10106107### 3d. Sling Scheduler108109**Check the Sling Scheduler status page (`/system/console/status-slingscheduler`):**110- This page lists Quartz-style schedulers, not Sling Job topics. On OOTB AEM 6.5 LTS the workflow-related entry visible here is the periodic `WorkflowStatsMBean` collector (used by the Statistics MBean) — its `nextFireTime` should be in the near future; `nextFireTime: null` means the trigger was deregistered.111- The `com/adobe/granite/workflow/timeout/job` topic itself is a **Sling Job**, not a Quartz job — check it on the Sling Jobs page (`/system/console/slingevent`), not here.112- Confirm `ApacheSlingdefault` uses `ThreadPool: default` — that's how the periodic timeout-detection scheduler reaches the workflow engine.113114---115116## Step 4: Error log patterns117118| Pattern | Cause | Action |119|---------|-------|--------|120| `Error executing workflow step` | Process step exception | Check stack; fix process code or payload |121| `getProcess for '<name>' failed` | No WorkflowProcess registered | Deploy bundle; match `process.label` |122| `Cannot archive workitem` | Archive failure → stale risk | JMX `restartStaleWorkflows` |123| `refreshing the session since we had to wait for a lock` | Lock contention | Tune `queue.maxparallel` on the Granite Workflow Queue (Apache Sling Job Queue Configuration); reduce concurrent writes to the same path |124| `Terminate failed` / `Resume failed` / `Suspend failed` | Permissions (not initiator/superuser) | Check `enforceWorkflowInitiatorPermissions`; add to superusers |125| `PathNotFoundException` (workflow/payload) | Payload/launcher path missing | Verify payload exists; check launcher config path |126| `Error adding launcher config` | Launcher config path not created | Create `/conf/global/settings/workflow/launcher/config` |127| `retrys exceeded - remove isTransient` | Transient workflow failed after retries | Fix process code; instance persisted for admin handling |128| `RejectedExecutionException` | Thread pool full with ABORT policy | Increase pool size or change policy to RUN; fix stuck threads |129| `Workflow is already finished` | Terminate on completed/aborted instance | Check logic calling terminate |130| `Workflow purge '<name>' : repository exception` | Purge JCR error | Check permissions; repo health |131132---133134## Step 5: Configuration checklist135136**In Felix Console → OSGi → Configuration (`/system/console/configMgr`):**137138| Config | Property | Check |139|--------|----------|-------|140| WorkflowSessionFactory | `cq.workflow.job.retry` | Default 3; increase for flaky steps |141| WorkflowSessionFactory | `cq.workflow.superuser` | Must include admin users/groups (OOTB list includes `admin`, `administrators`, `workflow-process-service`, `workflow-service`, `workflow-administrators`, `wcm-workflow-service`) |142| WorkflowSessionFactory | `granite.workflow.enforceWorkitemAssigneePermissions` | true (OOTB) = only assignee sees items |143| WorkflowSessionFactory | `granite.workflow.enforceWorkflowInitiatorPermissions` | true (OOTB) = only initiator (or superuser) can terminate/suspend/resume |144| WorkflowSessionFactory | `granite.workflow.inboxQuerySize` | Max work items returned per Inbox query. OOTB 2000; raise if heavy users hit the cap |145| WorkflowSessionFactory | `granite.workflow.maxPurgeSaveThreshold` | OOTB 20 — commit after this many purged instances. Raise carefully to reduce JCR overhead during large purges |146| WorkflowSessionFactory | `granite.workflow.maxPurgeQueryCount` | OOTB 1000 — JCR query batch size during purge. Tune with above |147| Granite Workflow Queue (`org.apache.sling.event.jobs.QueueConfiguration~workflow`) | `queue.maxparallel` | **Real parallelism knob.** OOTB on AEM 6.5 LTS is `0.5` (50% of CPU cores). Adobe's *Workflows Best Practices* recommends **between half and three-quarters of processor cores**. `cq.workflow.job.max.procs` displayed in Felix Config Manager is an **orphaned metatype label** with no code path that reads it (verified against source on `release/660` and `prod/cq660`) — do not rely on it. Verify the running value at `/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration~workflow` |148| DefaultThreadPool (`name=default`) | `block policy` | OOTB `RUN`. `ABORT` would silently drop workflow timeout jobs — keep `RUN` unless you have a specific reason |149| DefaultThreadPool (`name=default`) | `max pool size` | **OOTB on AEM 6.5 LTS is 5** (Apache Sling default). Bump to 20+ for environments with many custom periodic schedulers; otherwise the pool can starve under load |150| Purge Scheduler (`com.adobe.granite.workflow.purge.Scheduler`) | `scheduledpurge.daysold` | 30 default; tune per environment. Factory PID — deploy one config per schedule |151| Purge Scheduler | `scheduledpurge.workflowStatus` | Array-typed; e.g. `["COMPLETED"]` |152153---154155## Step 6: Remediation quick reference156157| Action | 6.5 LTS / AMS approach |158|--------|----------------------|159| Retry failed work item | JMX `retryFailedWorkItems` or Inbox Retry |160| Restart stale workflows | JMX `restartStaleWorkflows(dryRun=true)` then execute |161| Purge completed | JMX `purgeCompleted(dryRun=true)` or Purge Scheduler |162| Increase parallelism | Felix Console: `queue.maxparallel` on the Granite Workflow Queue (Apache Sling Job Queue Configuration); or OSGi config in repo |163| Fix thread pool exhaustion | Restart instance (immediate); fix stuck scheduler code; change block policy to RUN |164| Fix process not found | Deploy bundle; `process.label` must match; Sync model |165| Fix auto-advancement | Verify `default` pool not saturated; timeout jobs scheduled; block policy = RUN |166167---168169## Step 7: Key JMX MBeans170171All workflow maintenance and diagnostic operations live on a single MBean: `com.adobe.granite.workflow:type=Maintenance`. A separate MBean — `com.adobe.granite.workflow:type=Statistics` — exposes time-series workflow execution metrics for trend analysis.172173| MBean | Operations | Purpose |174|-------|------------|---------|175| `com.adobe.granite.workflow:type=Maintenance` | `purgeCompleted(model [optional], days, dryRun)`, `purgeActive(model [optional], days, dryRun)`, `countRunningWorkflows(model [optional])`, `countCompletedWorkflows(model [optional])`, `countStaleWorkflows(model [optional])`, `restartStaleWorkflows(model [optional], dryRun)`, `retryFailedWorkItems(dryRun, model [optional])`, `terminateFailedInstances(restart, dryRun, model [optional])`, `returnSystemJobInfo()`, `returnWorkflowQueueInfo()`, `returnWorkflowJobTopicInfo()`, `returnFailedWorkflowCount(model [optional])`, `returnFailedWorkflowCountPerModel()`, `listRunningWorkflowsPerModel()`, `listCompletedWorkflowsPerModel()`, `fetchModelList()` | Purge, stale detection/restart, retry failed items, bulk terminate, queue/job diagnostics, per-model counts and enumeration |176| `com.adobe.granite.workflow:type=Statistics` | `getResults`, `clearRecords`; plus `get`/`set` accessors for `DataLifeTime`, `DataFidelityTime`, `DataProcessRate`, `DataRate` | Time-series workflow execution statistics |177178**Always use `dryRun=true` first before executing destructive purge or retry operations.**179180---181182## Step 8: Common root cause patterns (from real incidents)183184### Pattern A: Thread pool starvation → auto-advance failure185186**Symptom:** Workflow auto-advancement stops; timeout jobs not firing; workflows stuck at participant step despite timeout configured.187188**Root cause chain:**1891. Custom scheduler (e.g. `AccessTokenScheduler`) makes blocking HTTP call without timeout1902. `concurrent = true` allows overlapping executions on each cron trigger1913. Each stuck execution consumes a `default` pool thread indefinitely1924. All pool threads consumed (OOTB on AEM 6.5 LTS that's only **5**; environments hardened for throughput typically run with 20+) → pool saturated1935. If block policy has been changed to `ABORT` (OOTB is `RUN`), new Quartz triggers are rejected silently; on `RUN` they instead pile up on the caller thread and back-pressure the dispatch1946. The workflow timeout-detection scheduler cannot dispatch new `com/adobe/granite/workflow/timeout/job` events1957. Auto-advancement never happens196197**Diagnosis checklist:**198- [ ] Sling Thread Pools page (`/system/console/status-slingthreadpools`): Pool `default` → active count = max pool size?199- [ ] Sling Thread Pools page: Pool `default` → block policy = ABORT?200- [ ] Threads page (`/system/console/status-Threads`) or jstack: All `sling-default-*` threads stuck on same stack?201- [ ] Sling Jobs page (`/system/console/slingevent`): Workflow job topic has high Failed Jobs?202- [ ] Sling Scheduler page (`/system/console/status-slingscheduler`): ThreadPool = `default` for `ApacheSlingdefault`?203204**Fix:** Restart instance (immediate); fix scheduler code (add HTTP timeout, set `concurrent=false`); change pool policy to RUN; increase pool size.205206### Pattern B: High workflow job failure rate207208**Symptom:** `numberOfFailedJobs` >> `numberOfFinishedJobs` for a workflow topic.209210**Root cause:** Process step exception, payload deleted, or process not registered.211212**Diagnosis:** Search error.log for `Error executing workflow step` + model name. Check `process.label` in Felix Console → OSGi Components.213214### Pattern C: Stale workflows accumulating215216**Symptom:** Workflows in RUNNING state but no work items; Inbox empty despite running instances.217218**Root cause:** `Cannot archive workitem` during transition; JCR session crash during step completion.219220**Diagnosis:** Search for `Cannot archive workitem`; JMX `countStaleWorkflows`; `restartStaleWorkflows(dryRun=true)`.221222---223224## References225226- For runbook locations: see [reference.md](reference.md)
Adobe