StdioClientTransport: Inbound Scheduler and Error Scheduler threads are locked on Windows

Bug description
Two threads, Inbound Scheduler and Error Scheduler, remain locked forever (at java.io.FileInputStream.readBytes native call) in io.modelcontextprotocol.client.transport.StdioClientTransport after the graceful shutdown is completed using closeGracefully method.

Looks like a Windows specific issue with native I/O calls. The problem is observed when running on Windows. No problems with Linux environment.

The thread dump is attached.
dump_jdk17.txt
See "pool-2-thread-1" and "pool-5-thread-1" dumps.

Environment
Windows 11 Enterprise
mcp-core 0.17.1
Spring AI 2.0.0-SNAPSHOT
JDK Temurin 17.0.14 (also tried Amazon Corretto 21.0.5)

Linux Behavior
Works fine under Ubuntu 24.04 and JDK Temurin 21.0.10

Steps to reproduce

• Run the steps from the Spring AI Filesystem Demo example on Windows.
• The Java application process is not terminated as expected.

Expected behavior
The Java process terminates after running the Spring AI Filesystem Demo example.

Possible solution
On Windows, use daemon threads for inbound and error schedulers

private ThreadFactory daemonThreadFactory = runnable -> {
		Thread t = new Thread(runnable);
		t.setDaemon(true);
		return t;
	};

if (isWindows) {
    this.inboundScheduler = Schedulers.fromExecutorService(Executors.newSingleThreadExecutor(daemonThreadFactory), "inbound");
    this.errorScheduler = Schedulers.fromExecutorService(Executors.newSingleThreadExecutor(daemonThreadFactory), "error");
}

Tried this solution locally. It resolves the termination issue. But the graceful shutdown logic in io.modelcontextprotocol.client.transport.StdioClientTransport#closeGracefully should be revised as well.

Inizia da io.modelcontextprotocol.client.transport.StdioClientTransport, concentrandoti su Inbound Scheduler, Error Scheduler e sul metodo closeGracefully, quindi esamina il thread dump di Windows allegato alla ricerca di letture bloccate. Riproduci Spring AI Filesystem Demo su Windows e verifica che l’arresto termini il processo Java senza lasciare bloccati i thread dello scheduler.