-
Improvement
-
Resolution: Won't Do
-
High
-
None
-
None
-
None
motivated by GENIUS-96
as per https://lists.opendaylight.org/pipermail/infrautils-dev/2017-November/000487.html
it seems to me that JobCoordinatorImpl unbounded datastructures are very risky, and that we should limit and reject new jobs at the time enqueueJob() is called if we're full, instead of OOM'ing.
NB there are at least 3 if not more datastructures here I see we need to protect:
- ForkJoinPool fjPool
- ScheduledExecutorService scheduledExecutorService
- Map<String, JobQueue> jobQueueMap keys
- Map<String, JobQueue> jobQueueMap internal JobQueue (separate from the keys)
And when JC is "full", it would probably be useful in future analysis to have a dump of all jobs that are stuck in the queue at that point? Or force a thread dump via INFRAUTILS-21 ?
- blocks
-
GENIUS-96 DataStoreJobCoordinator OOM
- Verified
- is blocked by
-
INFRAUTILS-21 Automatic deadlock detection logging
- Resolved