Repository navigation
TCP connections remain in CLOSE_WAIT state after client disconnection in SSE mode #378
Description
Activity
Perhaps you can try manually executing McpServerTransportProvider#notifyClients(McpSchema.METHOD_PING, null) on a scheduled basis.
I've encountered a similar issue, but in my case, it occurs when Nginx forwards requests to the MCP server. However, when testing disconnections using MCP Inspector v0.16.2, I couldn't reproduce the persistent CLOSE_WAIT state. Moreover, the ports in CLOSE_WAIT state still had one byte of unread data. I'm not sure where exactly the problem lies.
My solution was to limit the timeout duration for SSE connections. By default, it was set to 0. We locally overrode the WebMvcSseServerTransportProvider and modified Duration.ZERO to 60 in the handleSseConnection method.
However, this approach alters the fundamental nature of SSE long connections. So now, I'm trying the PING method mentioned above to see if it can resolve the issue.
Reacted by communityClosing due to inactivity.
Bug description
When clients terminate SSE connections with the Java MCP server, the underlying TCP connections remain in CLOSE_WAIT state, while the client side stays in FIN_WAIT_2. This can lead to resource leaks, especially in scenarios where clients cannot properly send RST signals (e.g., when using customized user-space network stacks).
Environment
java version: 17
sdk version: 0.10.0
spring-ai.version: 1.0.0
Steps to reproduce
Expected behavior
All TCP connections should be closed properly.