New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ByteBuf.release() was not called before it's garbage-collected #5978
Comments
The ByteBufs are passed to the application thread for processing. Are you using ServerInterceptors.useInputStreamMessages() or making your own MethodDescriptor.Marshaller? Are you specifying your own executor to ServerBuilder.executor()? |
@ejona86
|
Update : I removed the function call ServerBuilder.executor(). Now the server command looks like this :
But still I'm getting the same error. |
@Umang-Goel are you sure that's the right code? It's missing semicolons after the server builder. |
@carl-mastrangelo yes, it's correct. I made a typo while copying it here. |
If you were using blocking stub I could have more ideas of what is going wrong, but you're using async stub. And it doesn't appear you are using interceptors. So I don't really know how this could be happening. @Umang-Goel, do you have any idea on what type of RPC triggers this? I'd assume it isn't happening every RPC. The most likely places something like this could happen is in error-handling code paths. |
Unclear how to diagnose this more without a reproduction case. But we could add a |
@ejona86 @creamsoup any updates on this? do you need anything from us? |
@amandeepgautam thanks for the ping. |
@creamsoup What do you mean by "leak detector log"? Can you help us with the steps to collect these? |
the first log of this issue has the leak detector log. also see this link from netty. @amandeepgautam if you are also seeing similar issue, you can turn on the leak detection level even higher by providing jvm flag |
@ejona86 @creamsoup i have the same problem, the server memory usage continues to grow to the maximum available, my grpc-java version is 1.23, and my java version is 1.8.0_202, Is there any update?
|
1.23 is quite old. Please try newer versions. #7105 found some issue that can cause the leak, but we mostly considered it to be #6328 (which had been reverted) introduced in 1.27. The potential message leaking issue should have been improved by #7187 and #7798 (not merged yet). While not 100% sure if your case is caused by related/similar reason, it worths to upgrade (>1.33) and see if the problem persists. |
@voidzcy thank you for your reply, I found the server memory usage is stable at night , and the speed of memory leak is strongly related to the amount of requests, This is very puzzling,i will try the upgrade and watch,thanks again~ |
Hello @voidzcy, |
I'm closing this because it very well could have been fixed and we made improvements that will change the error message to provide us more information. If you see something resembling this, it is best to create a new issue and provide the dumped stack traces for us to identify the specific cause. It would be hard for users to determine if they are seeing the same issue. I will note that 1.49 fixed one leak, and the release-in-progress-1.53 fixes another. Both of those are caused by races in the retry code when calls are cancelled; using |
Please answer these questions before submitting your issue.
What version of gRPC are you using?
What did you expect to see?
No leak
Actual behavior
Flags used to launch jvm:
-Xmx256m
-XX:MaxDirectMemorySize=256m
Also getting below logs:
JVM version (e.g.
java -version
)Java(TM) SE Runtime Environment (build 8.0.5.26 - pap6480sr5fp26-20181115_03(SR5 FP26)) IBM J9 VM (build 2.9, JRE 1.8.0 AIX ppc64-64-Bit Compressed References 20181106_401576 (JIT enabled, AOT enabled) OpenJ9 - fde1d6f OMR - d8c3617 IBM - 5c4a9f0) JCL - 20181022_01 based on Oracle jdk8u191-b26
OS version (e.g.
uname -a
)I got the above log by setting
-Dio.netty.leakDetection.level=paranoid
.From the log it seems like
NettyServerHandler
does not correctly call release() on the ReferenceCounted objects it receives. But, I'm not explicitly usingNettyServerHandler
anywhere in the codebase. Though I'm using grpc and following are the classes which are being used:Do you have any idea which of these might be using the NettyServerHandler?
The text was updated successfully, but these errors were encountered: