ferenc-csaky commented on PR #25866: URL: https://github.com/apache/flink/pull/25866#issuecomment-2590313912
I am not sure I understand what https://github.com/apache/pekko/pull/1709 adds? I mean I see that it adds control over the `ByteBufAllocator`, but if we specify it directly via `io.netty.allocator.type` isn't that does the same? I do not think we should wait for another Pekko release for these patch releases, since the Netty version is carved into stone anyways, as it's coming through `flink-shaded`, and bumping that requires a whole different discussion AFAIK. Personally, I'd rather not complicate the defaults on the Flink side too much, so I do not think we should override `io.netty.allocator.type` by default. Maybe `unpooled` can be better in some cases, but I believe the default is picked on the Netty side to cover most use-cases the best, so sticking with that sounds reasonable to me. I did not spent time to learn an d analyze how much memory these reserve and how they work exactly, cause it seemed unnecessary. On the other hand, enabling reflection via `io.netty.tryReflectionSetAccessible=true` can be reasonable and I do not see risk in that, so setting that for both JM and TM can be an option, but I am not sure how many workloads this can actually affect, so that's why I had the idea to document it instead. -- 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: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
