@eolivelli also maybe interesting for you ^^
@normanmaurer this is the memory counter patch netty/netty#8945 thanks.
I am working on the heap dump (but it is huge), but I think that current discussion already helped me a lot in understanding the mechanics of using Netty allocators out side Netty threads. So I think I won't find much valueable data in the dump.
Hi, simple application which returns fastest result of two WebClient requests using Mono.first(). The application is failing with LEAK error:
2019-03-28 10:52:21.203 ERROR 25237 --- [or-http-epoll-4] io.netty.util.ResourceLeakDetector : LEAK: ByteBuf.release() was not called before it's garbage-collected. See http://netty.io/wiki/reference-counted-objects.html for more information.I prepared POC with full error logs: https://github.com/lradziwonowicz/spring-boot-webflux-webclient-netty-leak Should I create a bug or my approach is not correct?
it basically tells you release() was not called. I guess this should be done as part of the reactor / spring integration tho
@lradziwonowicz let’s discuss it here https://gitter.im/reactor/reactor You might want to try with the latest
Californium-SR6 (put this property <reactor-bom.version>Californium-SR6</reactor-bom.version> in the pom.xml)
Actially from the code - you consume just the status code and do not consume the body and thus your code will leak the memory
you might want to check these two links
bodyToMono(Void.class)
Any idea what could be causing it ?
Hi guys. I am working on Maven Surefire. We are going to rewrite the communication system between core Maven process and forked JVMs in tests, we are going to use loopback network instead of stdout/stdin. We are currently discussing about using Netty because it will make it very simple to implement the protocol and it is, you know, very efficient.
I have a concern about shading/relocating Netty bits and deploying it inside the forked JVM: this will "pollute" the environment for projects that are really using Netty.
May I have an opinion from any of you ?
I have a concern about shading/relocating Netty bits and deploying it inside the forked JVM: this will "pollute" the environment for projects that are really using Netty.
May I have an opinion from any of you ?
I think as it is only a test dependency I would not worry
that said I think you must shade
netty is too widely used to not shade
I would not be too concerned imho
as long as it is shaded
It seems the mpsc unbounded q, unless users specify a limit for the pending tasks...it is correct?
I'm waiting Nitsan to review (and I'm sure, improve) it :)
the XADD one ?
(following jctools as well)
I just need to undertand the use case: depends if the event loop mailbox is being stressed by multiple threads...starting from 2 the difference is "interesting" :)