Spring AI项目中MCP Server与Client通信的异常分析与解决方案

背景概述

在基于Spring AI框架构建的多通道协议(MCP)服务时，开发者可能会遇到一个典型问题：当MCP Server使用spring-ai-mcp-server-webmvc-spring-boot-starter实现时，客户端调用工具后频繁出现"OutputBuffer.isBlocking()空指针异常"，而改用WebFlux实现则不会出现此问题。这个现象揭示了Spring MVC与WebFlux在处理长连接时的底层差异。

问题现象深度解析

异常的核心表现为：

Failed to send message to session [会话ID]: Cannot invoke "org.apache.catalina.connector.OutputBuffer.isBlocking()" because "this.ob" is null

该异常通常发生在以下场景：

1. 客户端通过SSE(Server-Sent Events)与MCP Server建立长连接
2. 服务端处理完工具调用后尝试返回响应时
3. Tomcat容器的输出缓冲区(OutputBuffer)已被释放

根本原因在于：

• 传统的Spring MVC基于Servlet API，其同步处理模型与SSE的长连接特性存在固有矛盾
• 当客户端连接意外中断或超时时，Tomcat会回收输出缓冲区资源
• WebFlux基于Reactive Streams，天生更适合处理长连接场景

解决方案全景

方案一：调整Tomcat连接参数（推荐）

对于必须使用Spring MVC的场景，可通过调整服务器参数优化连接稳定性：

server:
  tomcat:
    connection-timeout: 180000  # 将连接超时设置为3分钟
    keep-alive-timeout: 120000 # 保持连接超时2分钟
    max-keep-alive-requests: 100 # 单个连接最大请求数

参数说明：

• connection-timeout：建立TCP连接后等待请求的超时时间
• keep-alive-timeout：保持空闲连接的最长时间
• 这些值需要根据实际业务流量特点进行调整

方案二：迁移至WebFlux实现（终极方案）

对于新项目或允许技术栈变更的场景，采用响应式编程模型是更彻底的解决方案：

@Configuration
@EnableWebFlux
public class McpWebFluxConfig {
    // 使用RouterFunction定义端点
    // 工具实现返回Mono/Flux类型
}

优势包括：

1. 非阻塞IO模型天然支持长连接
2. 更高效的资源利用率
3. 内置背压支持

方案三：完善客户端重试机制

增强客户端健壮性的补充措施：

@Bean(destroyMethod = "close")
public McpSyncClient mcpClient() {
    return McpClient.sync(new HttpClientSseClientTransport(serverUrl))
        .requestTimeout(Duration.ofSeconds(60))
        .retrySpec(Retry.backoff(3, Duration.ofMillis(500))) // 指数退避重试
        .build();
}

最佳实践建议

1. 监控与日志增强：在工具调用前后添加详细日志，记录会话状态和耗时
2. 连接健康检查：实现心跳机制维持连接活性
3. 资源清理：确保所有工具调用都有完善的超时处理和资源释放逻辑
4. 压力测试：模拟长时间运行和大并发场景验证稳定性

架构思考

这个问题反映了传统Servlet容器与现代实时通信需求之间的鸿沟。随着AI应用对实时交互要求的提高，开发者需要更深入地理解：

1. 同步vs异步处理模型的内在差异
2. 连接生命周期管理的艺术
3. 容器级配置对应用行为的影响

Spring AI框架在这方面的演进，正体现了从传统Web应用到智能服务架构的转型过程。理解这些底层机制，将帮助开发者构建更健壮的AI集成解决方案。

结语