René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Streamable HTTP client: slow reception of large SSE tool responses (fromLineSubscriber line-assembly bottleneck)","articleBody":"## Summary\n\nWhen a tool returns a large response over the Streamable HTTP **client** transport, the client takes ~5s to receive a ~4 MB body that `curl`/`HttpClient.ofString()` reads in ~0.4s. The bottleneck is the client-side SSE body reading in `ResponseSubscribers.sseToBodySubscriber`, not the server, network, or JSON parsing.\n\n## Environment\n\n- `io.modelcontextprotocol.sdk:mcp-core` / `mcp` **2.0.0** (latest)\n- JDK 25, Reactor (via SDK)\n- Server: Spring AI 2.0.0 `mcp-spring-webmvc` (`HttpServletStreamableServerTransportProvider`) returning a single large SSE `message` event — one compact-JSON `data:` line (~4.17 MB)\n- Client: `HttpClientStreamableHttpTransport` (`McpSyncClient.callTool`)\n\n## Measurements (steady-state, 3 runs)\n\n| Path | Time to receive ~4.17 MB |\n|---|---|\n| `McpSyncClient.callTool` (this SDK) | **~5,300 ms** |\n| Same payload via `curl` / `HttpClient` `BodyHandlers.ofString()` | ~0.4–0.75 s |\n| Jackson parse of the received JSON | \u003c 70 ms |\n\n→ ~10–13× slower than a plain one-shot read of the identical bytes.\n\n## Root cause analysis\n\nThe response body is effectively a single huge `data:` line (compact JSON has no newlines). `ResponseSubscribers.sseToBodySubscriber` uses `HttpResponse.BodySubscribers.fromLineSubscriber(...)`; assembling that one ~4 MB line through the JDK line subscriber is the cost.\n\nThings I tried:\n- Changing `SseLineSubscriber` demand from `upstream().request(1)` to `request(Long.MAX_VALUE)` → **no improvement** (so it isn't per-line backpressure).\n- Replacing the body subscriber with a **streaming byte-level SSE parser** (`BodySubscribers.fromSubscriber`, unbounded demand, accumulate `ByteBuffer`s, split on `\\n\\n` event boundaries, decode each event once) → **~0.4 s (≈13×)**.\n\n## Important constraint (must stay streaming)\n\nA whole-body `ofString` read fixes the speed but **breaks progress**: the server interleaves `notifications/progress` on the *same* POST response SSE stream before the final result. So the fix must remain a **streaming** parser that emits each SSE event as its boundary arrives (a byte-level parser does this while still avoiding the line-assembly cost).\n\n## Questions\n\n1. Is there a recommended approach/workaround for large tool responses on the client that we're missing?\n2. Would you accept a PR replacing `fromLineSubscriber` with a streaming byte-level SSE parser in `ResponseSubscribers.sseToBodySubscriber` (preserving incremental event emission)?\n3. Is this related to #844 (opt-in `application/json` response mode)? That would avoid SSE framing on the server side, but clients receiving SSE responses would still benefit from this fix.\n\nHappy to open a PR with the streaming parser + a benchmark if that's welcome.","author":{"url":"https://github.com/TaJoal","@type":"Person","name":"TaJoal"},"datePublished":"2026-06-28T00:29:09.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/1042/java-sdk/issues/1042"}