While integrating the Java MCP SDK 2.0, we noticed that HttpServletStreamableServerTransportProvider stores McpStreamableServerSession instances in an internal private HashMap, but currently does not expose a public API to inspect or remove server sessions.
Currently, the SDK does not expose any API to inspect, invalidate, or remove these sessions programmatically. The only supported way to remove a session appears to be an explicit HTTP DELETE request from the client.
This becomes problematic if a client terminates unexpectedly (application crash, network failure, process termination ...) and never sends the DELETE request. In this case, the server application has no possibility to clean up abandoned sessions, even if it can determine (e.g.: via an idle timeout) that a session has not been used for hours or days.
From our understanding, this means that the internal session map may continue to grow over time, as applications cannot implement their own session cleanup strategy.
We searched the existing issues and found discussions around session lifecycle management and pluggable session stores (e.g.: issue #274). However, we could not find an issue addressing the missing API to inspect and remove abandoned sessions managed by HttpServletStreamableServerTransportProvider.
Would it be possible to expose a public server-side session management API (e.g.: removeSession(), getSessions(), or a pluggable SessionStore/SessionManager) to allow applications to implement idle timeout and cleanup strategies for stateful Streamable HTTP servers?
While integrating the Java MCP SDK 2.0, we noticed that HttpServletStreamableServerTransportProvider stores McpStreamableServerSession instances in an internal private HashMap, but currently does not expose a public API to inspect or remove server sessions.
Currently, the SDK does not expose any API to inspect, invalidate, or remove these sessions programmatically. The only supported way to remove a session appears to be an explicit HTTP DELETE request from the client.
This becomes problematic if a client terminates unexpectedly (application crash, network failure, process termination ...) and never sends the DELETE request. In this case, the server application has no possibility to clean up abandoned sessions, even if it can determine (e.g.: via an idle timeout) that a session has not been used for hours or days.
From our understanding, this means that the internal session map may continue to grow over time, as applications cannot implement their own session cleanup strategy.
We searched the existing issues and found discussions around session lifecycle management and pluggable session stores (e.g.: issue #274). However, we could not find an issue addressing the missing API to inspect and remove abandoned sessions managed by HttpServletStreamableServerTransportProvider.
Would it be possible to expose a public server-side session management API (e.g.: removeSession(), getSessions(), or a pluggable SessionStore/SessionManager) to allow applications to implement idle timeout and cleanup strategies for stateful Streamable HTTP servers?