https://bz.apache.org/bugzilla/show_bug.cgi?id=68692

            Bug ID: 68692
           Summary: Http11Nio2Protocol not using provided executor
           Product: Tomcat 9
           Version: 9.0.83
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: gabor.b...@blackrock.com
  Target Milestone: -----

We're using NIO2 with a StandardThreadExecutor we declared in our server.xml,
and noticed in our logs that REST controllers run in a default thread pool,
i.e. thread names in the format Thread-x are logged, e.g.

2024-02-29 14:42:48,313 (Thread-6:[]) INFO ...

Upon further debugging we noticed that the threadGroup field of the
Nio2Endpoint is NULL. Looking at the source code, it seems that this condition
in the bind() method evaluates to false:

if (getExecutor() instanceof ExecutorService) {
            threadGroup =
AsynchronousChannelGroup.withThreadPool((ExecutorService) getExecutor());
}

which makes sense, since StandardThreadExecutor doesn't implement
ExecutorService. We suspect that the NULL threadGroup causes NIO2 to use the
default thread pool.

If we specify the thread attributes on the connector itself instead of passing
an executor attribute, the correct channel group/thread pool is used:

2024-02-29 15:15:07,166 (http-nio2-1776-exec-7:[]) INFO ...

since in that case, the endpoint instantiates a standard ThreadPoolExecutor
which implements ExecutorService.

       if (getUseVirtualThreads()) {
            executor = new VirtualThreadExecutor(getName() + "-virt-");
        } else {
            TaskQueue taskqueue = new TaskQueue();
            TaskThreadFactory tf = new TaskThreadFactory(getName() + "-exec-",
daemon, getThreadPriority());
            executor = new ThreadPoolExecutor(getMinSpareThreads(),
getMaxThreads(), 60, TimeUnit.SECONDS,taskqueue, tf);
            taskqueue.setParent( (ThreadPoolExecutor) executor);
        }

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to