chibenwa commented on pull request #886: URL: https://github.com/apache/james-project/pull/886#issuecomment-1059248623
Follow up regarding https://github.com/apache/james-project/pull/886#issuecomment-1058845783 ## Issue 1 We reproduced the bug on master thus this is not a regression. This bug will thus be handled separately cf https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3722 ## Issue 2 We confirm the ordering of the actual writes on the channel is not necessarily the same as those specified in the code (channel.writeAndFlush(xxx)). We solved the issue by awaiting that the write is done in `ChannelImapResponseWriter` (which is a terrible practice). @Arsnael will share us that version of the code. I'd like also to try something relying on future chaining, relying on `channel.writeAndFlush(data, previousFuture);` and carrying over the futures of the pending writes to enforce ordering without blocking. More on this later... ## Issue 3 No progress yet. ## Issue 4 No progress yet. ## Issue 5 More buffer leaks. @Arsnael spotted this: ``` 09:15:59.804 [ERROR] i.n.u.ResourceLeakDetector - LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information. Recent access records: Created at: io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:402) io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) io.netty.handler.ssl.SslHandler.allocate(SslHandler.java:2247) io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1336) io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1234) io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1283) io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507) io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:446) io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722) io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658) io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584) io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) 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(Unknown Source) ``` We need to be sure we run with `-Dio.netty.leakDetectionLevel=advanced` cc @Arsnael What's weird to me is that it seems allocated by SSLHandler thus logically the SSLHandler is responsible of releasing the buffer, not us. Also from what I could see `ByteToMessageDecoder` manages the buffers for `ImapRequestFrameDecoder` ... Should we try opening a bug report upstream to the Netty project? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
