Optimization - avoid unnecessary payload copy when deserializing

@chemicL

This issue suggests creating a JSON deserialization variant that consumes an InputStream without the need for a String copy of the HTTP request payload, reducing the GC pressure and improving overall performance.

Expected Behavior

Efficient correct HTTP
bad user data should return 400

Current Behavior

Bad data returns 5xx
Extrac copies of JSON messages are created in memory

Context

More memory pressure,
harder to debug

(edit by @chemicL)
The PR addressing this is #157

More efficient http modelcontextprotocol#156

Hello. Do you mind giving this a look. I am on vacation this week so if you want to get some cleanups out of me this is the week :)

More efficient http modelcontextprotocol#156

Third rebase as others include fixes inside this PR. Please have a look thank you.

This issue was raised some time ago and the SDK has evolved in the meantime. Is the described problem still applicable? Can you provide a test case demonstrating what behaviour you would expect?

Reading the issue description and then the context makes me feel a huge sense of ambiguity. Can you please enhance the description if this issue is still relevant? Thanks.

@chemicL

@chemicL

Well slap me around and call Suzy. You are right this is an old PR. Because no one from your community EVER reviews anything that doesnt come from a certain 'click'. Congrats on the new found "community engagement'!

Are you a real person or AI. Do plan on accepting ANY of my prs? Or just throw out some boilerplate statments like "I dont understand?" every 6 month.

The issue is quite clear, you dont turn go stream-string-object when you can go stream-object. That is what this PR does. The PR does not need new tests, the existing tests hits this path indirectly. Many of the other things i fix are bad style, or less then ideal code.

I already re based this 3 times as a begged for review, I dont want to bother doing it again, let me know if your serious about wanting to review without 7 month turn arounds.

This does not look like a PR to me. I understand the frustration for not getting enough attention. We are committed to a more systematic issue triage from now on. At the beginning we were mostly focusing on implementing the spec and catching up. Hopefully we can collaborate in a more organized manner. Also, please do check our contributing guidelines and discuss changes to agree whether the change is desired before opening PRs (unless this was the case).

public static JSONRPCMessage deserializeJsonRpcMessage(ObjectMapper objectMapper, String jsonText)
		throws IOException {



public static JSONRPCMessage deserializeJsonRpcMessage(ObjectMapper objectMapper, BufferedReader inputStream) {

My refactor started because I saw this in the code: This doesn't belong in a sever. stream-> buffer->json. Its obviously a 'quick and dirty'.

		BufferedReader reader = request.getReader();
			StringBuilder body = new StringBuilder();
			String line;
			while ((line = reader.readLine()) != null) {
				body.append(line);
			}

			McpSchema.JSONRPCMessage message = McpSchema.deserializeJsonRpcMessage(objectMapper, body.toString());

This is the change. Do you want it yes or no ? Its not something I need to bring up as a discussion... "inefficient http" the rest are style cleanups.

Let me link #157 as I believe this is the actual PR.

@chemicL

@chemicL

I see the root thing I am trying to solve is still in master "inefficient http"

java-sdk/mcp-core/src/main/java/io/modelcontextprotocol/server/transport/HttpServletStatelessServerTransport.java

Line 162 in 7dd609c

    
           McpSchema.JSONRPCMessage message = McpSchema.deserializeJsonRpcMessage(jsonMapper, body.toString());

Do you understand why this isnt the most efficient way? I think it is rather obviously and if I form a "discussion" I doubt anyone will reply for 9 months.

So you are proposing that instead of:

McpSchema.JSONRPCMessage message = McpSchema.deserializeJsonRpcMessage(objectMapper, body.toString());

a more efficient approach is to avoid the copy:

McpSchema.JSONRPCMessage message = McpSchema.deserializeJsonRpcMessage(objectMapper, request.getReader());

Now the current (as of 0.18.0-SNAPSHOT) implementation is decoupled from Jackson. In order to make it work, the McpJsonMapper interface would need to be adapted. I wonder if there is a way to avoid the copy with this design.

	public static JSONRPCMessage deserializeJsonRpcMessage(McpJsonMapper jsonMapper, String jsonText)
			throws IOException {
		var map = jsonMapper.readValue(jsonText, MAP_TYPE_REF);
		// ...
	}

Is see the value in this proposal, however it would need to be re-evaluated. If it can be introduced as a non-breaking additive change and the implementors of McpJsonMapper agree, let's do it.

@edwardcapriolo

@edwardcapriolo let me change the title of this issue to be more precise.

Looking at the Jackson API I think it's a viable proposal. Please rebase, cleanup your PR to remove the unrelated changes, and ping me for review if you are still interested. I do apologize for not giving this more attention before. Please also bear in mind that the more precise and adequate issue description and care given to it raises the chances that maintainers triage properly and accept a contribution.

Please also bear in mind that the more precise and adequate issue description and care given to it raises the chances that maintainers triage properly and accept a contribution.

10 months ago I did several PRs, I also tried to help by reviewing other PRs sent to the list (one that I see you closed today). The "vibe" I got was 'ignored'. I even did a PR fixing 0 day spelling mistakes, someone else did similar spelling mistake PR and got it merged in a day. The "vibe" I got was "UR not in the club".

I do appreciate that you are trying now. So Ill give it another go.

Navigation Menu

Repository navigation

Optimization - avoid unnecessary payload copy when deserializing #156

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Optimization - avoid unnecessary payload copy when deserializing #156

Description

Activity

edwardcapriolo commented on Apr 15, 2025

edwardcapriolo commented on Apr 16, 2025

chemicL commented on Feb 17, 2026

edwardcapriolo commented on Feb 17, 2026

chemicL commented on Feb 17, 2026

edwardcapriolo commented on Feb 17, 2026

chemicL commented on Feb 17, 2026

edwardcapriolo commented on Feb 17, 2026

chemicL commented on Feb 17, 2026

chemicL commented on Feb 17, 2026

chemicL commented on Feb 17, 2026

edwardcapriolo commented on Feb 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions