How to properly destroy the MCP Server? Orphan Threads in Tomcat #650

i23098 · 2025-11-04T14:32:31Z

i23098
Nov 4, 2025

Pre-submission Checklist

I have checked that this question would not be more appropriate as an issue in a specific repository
I have searched existing discussions and documentation for answers

Question Category

Your Question

I implemented a very basic Hello World MCP server - https://github.com/i23098/mcp-server-java

On the servlet destroy method, it destroys the server by doing:

        this.mcpServer.close();
        
        this.transportProvider.close();
        this.transportProvider.destroy();

I use the MCP Inspector to test the server, works fine, responds, all ok...

But, if I do some code changes and redeploy the war (i.e. copy a new war to the tomcat webapps directory), I get some errors related to threads not being stopped:

04-Nov-2025 14:23:19.951 WARNING [Catalina-utility-2] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [hello-world-mcp] appears to have started a thread named [boundedElastic-evictor-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 java.base/jdk.internal.misc.Unsafe.park(Native Method)
 java.base/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:269)
 java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1763)
 java.base/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
 java.base/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
 java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1070)
 java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
 java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
 java.base/java.lang.Thread.run(Thread.java:1583)
04-Nov-2025 14:23:19.952 WARNING [Catalina-utility-2] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [hello-world-mcp] appears to have started a thread named [boundedElastic-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 java.base/jdk.internal.misc.Unsafe.park(Native Method)
 java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:371)
 java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(AbstractQueuedSynchronizer.java:519)
 java.base/java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:3780)
 java.base/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3725)
 java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1712)
 java.base/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1170)
 java.base/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
 java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1070)
 java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
 java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
 java.base/java.lang.Thread.run(Thread.java:1583)

Is this a bug or am I missing something in the destroy()?

shmulc8 · 2026-09-30T22:33:40Z

shmulc8
Sep 30, 2026

Your sample pins Java SDK 0.15.0. In that version, the server's close() delegates to the transport, whose closeGracefully() only marks it as closing. It does not dispose Reactor's shared boundedElastic scheduler; that matches the thread names Tomcat reports.

At webapp shutdown, after closing the MCP server, Schedulers.shutdownNow() is worth testing if this WAR owns its Reactor runtime. Reactor says it disposes all cached schedulers, so do not call it per servlet if other live components share that runtime. Your separate transportProvider.close() is redundant because server close already delegates to it.

Sources: SDK 0.15.0 server close, servlet transport, and Reactor Schedulers.

0 replies

Navigation Menu

How to properly destroy the MCP Server? Orphan Threads in Tomcat #650

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

How to properly destroy the MCP Server? Orphan Threads in Tomcat #650

Uh oh!

i23098 Nov 4, 2025

Pre-submission Checklist

Question Category

Your Question

Replies: 1 comment

Uh oh!

shmulc8 Sep 30, 2026

i23098
Nov 4, 2025

shmulc8
Sep 30, 2026