versionpurge job getting Job Queue stuck.
- Dominant language
- Java
- Stars
- 593
- Forks
- 123
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 4
Description
## Gentics Mesh Version, operating system, or hardware.
- v1.8.2
## Operating System
- Linux, mesh instance dockerized
## Problem
- There are some version purge jobs in the list. When we re-queue these jobs, the cms instance starts a deadlock. This deadlock makes the instance stop responding to API calls.
- When we restart the instance, that job is still in the queue (not failed). if re-queue another job, the cms instance still takes the first version purge job ( 1st job in the queue ) instead. and the same process happens (deadlock and cms getting not responsive)
- Because of this, all other jobs got stuck in the queue. We cannot make any schema changes. All schema migration jobs are in the job list and cannot be processed.
problematic job:
``` json
{
"uuid": "16eadf6a89a8486e9da27546ac854ee7",
"created": "1970-01-01T00:00:00Z",
"type": "versionpurge",
"status": "QUEUED",
"properties": {
},
"completionCount": 0,
"warnings": [
]
}
```
## Reproducer
- reprocessing jobs via API re-produce the same problem.
## Expected behaviour and actual behaviour.
- Job should either fail or got completed.
Contributor guide
Research direction
Start by reproducing the versionpurge job behavior through the job reprocessing API on Gentics Mesh v1.8.2 running on Linux in Docker, using the provided queued job details. Trace why re-queuing causes a deadlock and leaves later jobs blocked; done means the version purge job fails or completes and the remaining queue can process schema migration jobs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, java
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100