When deploying a Java EE 8 servlet into Tomcat 9.0.89 in which the servlet uses the the EJB client to invoke on a remote EJB deployed on a Wildfly 26.1.3 server, the following is observed after undeployment of the servlet (thanks to Andrea Vettori for the example):

// I/O-1 thread
22-Oct-2024 21:24:44.249 WARNING [Catalina-utility-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [TestApp] appears to have started a thread named [XNIO-1 I/O-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.base@17.0.13/sun.nio.ch.KQueue.poll(Native Method)
java.base@17.0.13/sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:122)
java.base@17.0.13/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:129)
java.base@17.0.13/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141)
org.xnio.nio.WorkerThread.run(WorkerThread.java:551)

// Accept thread
22-Oct-2024 21:24:44.249 WARNING [Catalina-utility-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [TestApp] appears to have started a thread named [XNIO-1 Accept] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.base@17.0.13/sun.nio.ch.KQueue.poll(Native Method)
java.base@17.0.13/sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:122)
java.base@17.0.13/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:129)
java.base@17.0.13/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:146)
org.xnio.nio.WorkerThread.run(WorkerThread.java:532)

// Task-1 thread
22-Oct-2024 21:24:44.249 WARNING [Catalina-utility-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [TestApp] appears to have started a thread named [XNIO-1 task-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.base@17.0.13/jdk.internal.misc.Unsafe.park(Native Method)
java.base@17.0.13/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252)
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1421)
org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1282)
java.base@17.0.13/java.lang.Thread.run(Thread.java:840)

// task-2 thread
22-Oct-2024 21:24:44.249 WARNING [Catalina-utility-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [TestApp] appears to have started a thread named [XNIO-1 task-2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.base@17.0.13/jdk.internal.misc.Unsafe.park(Native Method)
java.base@17.0.13/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252)
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1421)
org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1282)
java.base@17.0.13/java.lang.Thread.run(Thread.java:840)

22-Oct-2024 21:24:44.250 SEVERE [Catalina-utility-1] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [TestApp] created a ThreadLocal with key of type [java.lang.ThreadLocal.SuppliedThreadLocal] (value [java.lang.ThreadLocal$SuppliedThreadLocal@549add58]) and a value of type [org.wildfly.common.context.ContextManager.State] (value [org.wildfly.common.context.ContextManager$State@6d3ef70a]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

...

22-Oct-2024 21:24:44.251 SEVERE [Catalina-utility-1] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [TestApp] created a ThreadLocal with key of type [java.lang.ThreadLocal.SuppliedThreadLocal] (value [java.lang.ThreadLocal$SuppliedThreadLocal@6df8eab9]) and a value of type [org.xnio.ByteBufferPool.DefaultCache] (value [org.xnio.ByteBufferPool$DefaultCache@53a262c8]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

and threads in the XnioWorker are still running:

"XNIO-1 I/O-1" #107 daemon prio=5 os_prio=31 cpu=84.15ms elapsed=493.85s tid=0x000000012e868a00 nid=0x13203 runnable [0x000000031b11a000]
"XNIO-1 Accept" #108 daemon prio=5 os_prio=31 cpu=0.10ms elapsed=493.85s tid=0x000000012e865e00 nid=0x12503 runnable [0x000000031b326000]
"XNIO-1 task-1" #115 daemon prio=5 os_prio=31 cpu=27.34ms elapsed=493.65s tid=0x000000012f00c600 nid=0x12c17 waiting on condition [0x000000031b94a000]
"XNIO-1 task-2" #116 daemon prio=5 os_prio=31 cpu=0.41ms elapsed=493.51s tid=0x0000000151a7c600 nid=0x12e03 waiting on condition [0x000000031bb56000]

The XnioWorker has methods for cleanly shutting down (shutdown()/shutdownNow()) but from visual examination, these don't seem to be called when the XnioWorker instance is associated with a ContextManager<XnioWorker>.