Uploaded image for project: 'infrautils'
  1. infrautils
  2. INFRAUTILS-24

JobCoordinator should use bounded Executors and bound its own job queue

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Won't Do
    • Icon: High High
    • None
    • None
    • jobcoordinator
    • 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 ?

            Unassigned Unassigned
            vorburger Michael Vorburger
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: