try fix session potential leak by server sse ping

[taobaorun]

Motivation and Context

Streamable Potential session leaks when Client Fails to Invoke DELETE

Problem:

The current implementation can leak server-side sessions under the following conditions:

a. Session accumulation due to missing DELETE calls

When a client repeatedly establishes new connections but never issues the required DELETE request, the sessions map inside WebMvcStreamableServerTransportProvider grows unbounded.

i. Explicit DELETE is mandatory
Streamable clients must call the DELETE method when they are destroyed to ensure the server cleans up the corresponding session.
b. Client restarts prevent DELETE execution
If the client process (or container) is restarted before it has a chance to send the DELETE, the server retains the now-orphaned session indefinitely, leading to a rapid accumulation of stale entries.

How Has This Been Tested?

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[chemicL]

According to the specification, sessions are rather permanent (outlive the client connection) and removing sessions should happen explicitly via a DELETE call by the client. The specification does not explain when sessions are removed so perhaps we could add a mechanism for the server to decide, e.g. introduce a TTL for inactive sessions. However, client disconnects should not trigger session removal unless explicitly configured that way (another strategy outside of TTL?). I'd suggest we discard this contribution and open a discussion in another issue, WDYT @tzolov ?

[taobaorun]

According to the specification, sessions are rather permanent (outlive the client connection) and removing sessions should happen explicitly via a DELETE call by the client. The specification does not explain when sessions are removed so perhaps we could add a mechanism for the server to decide, e.g. introduce a TTL for inactive sessions. However, client disconnects should not trigger session removal unless explicitly configured that way (another strategy outside of TTL?). I'd suggest we discard this contribution and open a discussion in another issue, WDYT @tzolov ?

I think we need ttl

[taobaorun]

java-sdk/mcp-spring/mcp-spring-webmvc/src/main/java/io/modelcontextprotocol/server/transport/WebMvcSseServerTransportProvider.java

Line 313 in 6ec443c

sessions.remove(sessionId);

Here, with reference to the SSE implementation, cleanup is triggered when the SSE connection ends.

[Damore]

Also, this problem affects the WebFluxStreamableServerTransportProvider as well. Here we can clearly see this leak happening on the logs, due to the KeepAliverScheduler

The @taobaorun's suggestion of having a TTL sounds interesting, but what also seems a good choice, is to have a max number of keep-alive failure and, after that, we remove the session on the server.

Finally, one thing that calls my attention is that we have the method handleGet on the sink.onDispose. However, when the client disconects, it never invokes this flow.

On the other hand, it correctly calls on the class WebFluxSseServerTransportProvider on the method handleSseConnectionon the sink.onCancel

[taobaorun]

have a max number of keep-alive failure and, after that, we remove the session on the server.

I think it's a simple and effective solution. Just like this pr, it also attempts to solve the problem through ping.

[Damore]

@chemicL Waiting for your feedback on my comment as well