Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-2793

Consolidate scheduled thread pool usage

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Major
    • None
    • None
    • None

    Description

      Look into whether we can consolidate thread usage for scheduled tasks.

      1) Get rid of the "DeploymentScanner Threads" pool

      The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in general to allow use of this pool by subsystems as scheduled executors have a fixed size pool, so arbitrary usage by subsystems can result in tying up all the threads doing long running tasks and undesirable behavior. But deployment-scanner is "kernel-ish enough" that I think it's ok.

      This will remove 2 threads.

      The server scheduled executor has 4 threads which is actually pretty high given the very limited usage of it. So I'll consider narrowing it down.

      The big problem with using the server scheduled executor is tying up its threads long running tasks, which the scanner does do. What i'll probably do is just use the scheduled executor to trigger a task which then submits a task on the main ServerService thread pool (which is unlimited in size.)

      Perhaps I'll abstract this kind of usage pattern into a service, and make that service a generally available kernel capability.

      2) Get rid of the "ServerDeploymentRepository-temp-threads" pool

      This one is used by DeploymentMountProvider to do file cleanup. Similar discussion applies.

      Attachments

        Activity

          People

            bstansbe@redhat.com Brian Stansberry
            bstansbe@redhat.com Brian Stansberry
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: