You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When deploying in a cluster, I connect through the domain name. Since SSE is a long-lived, stateful protocol, the intermediate network proxy layer (such as Nginx) is configured with routing rules to ensure that the same client request is routed to the same MCP server, for example, IP Hash.
On one hand, this issue will not be solved for the legacy SSE transport type due to its' design. We can address the problem for Streamable HTTP in two ways:
use the Stateless transport variants (losing the bi-directional nature)
implement a persistent session storage
There is a drawback with the current Streamable HTTP specification though, which assumes the client first initializes with the server. In case of multiple replicas of the server, the replicas that have not seen the client might just fail, that's implementation specific, not addressed by the MCP Specification. There is a current effort to implement a Stateless-by-default Streamable HTTP specification, which would help resolve this.
I intend to keep the issue open as implementing the session storage will be crucial for the upcoming spec changes and we could perhaps relax the initialization requirement to make scalability with sessions possible.
Activity
hongling-dev commentedon Apr 28, 2025
When deploying in a cluster, I connect through the domain name. Since SSE is a long-lived, stateful protocol, the intermediate network proxy layer (such as Nginx) is configured with routing rules to ensure that the same client request is routed to the same MCP server, for example, IP Hash.
hongling-dev commentedon Apr 28, 2025
'Streamable HTTP Transport' can solve or alleviate this problem
yu199195 commentedon Apr 29, 2025
@lambochen thanks~
chensi2017 commentedon Apr 29, 2025
java什么时候才能支持streamable http呢
lvchengwei0901 commentedon May 9, 2025
这个当前有解决方案吗?
chemicL commentedon Feb 17, 2026
On one hand, this issue will not be solved for the legacy SSE transport type due to its' design. We can address the problem for Streamable HTTP in two ways:
There is a drawback with the current Streamable HTTP specification though, which assumes the client first initializes with the server. In case of multiple replicas of the server, the replicas that have not seen the client might just fail, that's implementation specific, not addressed by the MCP Specification. There is a current effort to implement a Stateless-by-default Streamable HTTP specification, which would help resolve this.
I intend to keep the issue open as implementing the session storage will be crucial for the upcoming spec changes and we could perhaps relax the initialization requirement to make scalability with sessions possible.
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments
fix: sync MCP sessions to Redis for multi-replica deployments (#3491)
Kehrlann commentedon Sep 4, 2026
Sessions are not supported in the new 2026-07-28 spec. We won't implement session storage for the older versions.