René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Session+Transport tied lifecycle doesn't easily support stateless connections such as StreamableHttp","articleBody":"Hello,\n\nI'm trying to build an MCP server that uses the StremeableHttp transport (for which I created my own implementation). Although I finally got it to work, I found what I believe to be a design flaw in the way that McpAsyncServer -\u003e McpServerSession -\u003e Transport lifecycle are coupled and tied together. Let me explain:\n\nRight now, the Session and Transport pretty much share the same lifecycle. They are created, used and stopped together. This works well for stdio and SSE transports, since those are stateful connections and the act of `reconnecting` results in brand new Session and Transport instances being created. This design works for SSE and will work for any other type of stateful connections (e.g: an eventual WebSockets transport).\n\nThis however doesn't work for stateless connection types such as streamable http, in which the session is created when the first initialize request is received but has a lifecycle that survives across many distinct http requests (even concurrent ones). \n\nIMO, the root cause of the problem is that the McpServerTransport is missing the concept of `TransportRequest`  or `TransportMessage`. Furthermore, the fact that the `McpServerTransportProvider` creates new `Transport` instances  per each new request or session, suggests to me that the Transport is kind of partially assuming responsibilities that would better fit a request object. \n\nUsing StremeableHttp as an example, the advantages of introducing this `Request` object would be the following:\n\n* `TransportProvider` dissapears and becomes simply `McpServerTransport`\n* Whenever a JsonRPCMessage is received, the `McpServerTransport` instantiates a new `TransportRequest` object that will contain all the relevant information. In the case of StremeableHttp, it would contain the HttpRequest object, some kind of callback or Writer to generate the response, client connection information, etc. NOTE: This would also make it quite easier to get that information than it is today, making things like security and tracing easier to implement\n* When needed, the `McpServerTransport` will use the `McpServerSessionFactory` to create new sessions. The session is then capable of handling further requests. \n* At this point, the lifecycle of all three components have been completely decoupled. Processing concurrent messages over stateless connections is now much much simpler than today\n\n","author":{"url":"https://github.com/marianogonzalez","@type":"Person","name":"marianogonzalez"},"datePublished":"2025-05-28T16:01:02.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/273/java-sdk/issues/273"}