基于 HTTP1/2 的 RPC 通信协议 - triple

dubbo-rpc-triple:3.3.6
Netty:4.2.9 使用直接内存的方式
jdk:17.0.17
windows
/**
* Triple 直连服务引用
*/
@DubboReference(
version = "1.0.0",
url = "tri://${dubbo.directUrl}",
protocol = "tri",
check = false,
timeout = 100, //将timeout设成比较小的值模拟超时，运行一段时间 netty的内存泄露检查就会检测到ByteBuf没有及时释放
connections = 5,
actives = 5

)
private TripleExternalService tripleService; 这是我的服务接口
添加了 netty 泄露检测 -Dio.netty.leakDetectionLevel=PARANOID

持续一段时间调用 rpc接口的某个方法
while(true){
tripleService.XXX();
//sleep 一会
}
跑一段时间就会有报错信息 换成Dubbo协议就没有
这是netty底层报错信息：
io.netty.buffer.AdvancedLeakAwareByteBuf.readByte(AdvancedLeakAwareByteBuf.java:401)
io.netty.handler.codec.http2.DefaultHttp2FrameReader.preProcessFrame(DefaultHttp2FrameReader.java:190)
io.netty.handler.codec.http2.DefaultHttp2FrameReader.readFrame(DefaultHttp2FrameReader.java:146)
io.netty.handler.codec.http2.Http2InboundFrameLogger.readFrame(Http2InboundFrameLogger.java:39)
io.netty.handler.codec.http2.DefaultHttp2ConnectionDecoder.decodeFrame(DefaultHttp2ConnectionDecoder.java:186)
io.netty.handler.codec.http2.DecoratingHttp2ConnectionDecoder.decodeFrame(DecoratingHttp2ConnectionDecoder.java:61)
io.netty.handler.codec.http2.Http2ConnectionHandler$FrameDecoder.decode(Http2ConnectionHandler.java:391)
io.netty.handler.codec.http2.Http2ConnectionHandler.decode(Http2ConnectionHandler.java:451)
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:545)
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:484)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:356)
io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:293)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:354)
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1429)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:918)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:172)
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.handle(AbstractNioChannel.java:445)
io.netty.channel.nio.NioIoHandler$DefaultNioRegistration.handle(NioIoHandler.java:388)
io.netty.channel.nio.NioIoHandler.processSelectedKey(NioIoHandler.java:596)
io.netty.channel.nio.NioIoHandler.processSelectedKeysOptimized(NioIoHandler.java:571)
io.netty.channel.nio.NioIoHandler.processSelectedKeys(NioIoHandler.java:512)
io.netty.channel.nio.NioIoHandler.run(NioIoHandler.java:484)
io.netty.channel.SingleThreadIoEventLoop.runIo(SingleThreadIoEventLoop.java:225)
io.netty.channel.SingleThreadIoEventLoop.run(SingleThreadIoEventLoop.java:196)
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:1195)
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
java.base/java.lang.Thread.run(Thread.java:842)
是不是 triple协议在这种场景下 有问题 ？

Start by reproducing the reported Triple call loop with JDK 17, Netty 4.2.9, timeout 100, five connections and actives, direct memory, and PARANOID leak detection. Trace the tripleService.XXX() path against the HTTP/2 stack shown; done means identifying whether the leak is in Triple handling and documenting or fixing the confirmed cause.

Written by the indexing model from the issue text.