-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Unable to close client properly #1412
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
Labels
Comments
Contributions welcome :) |
Yes I can contribute but I mentioned some alternatives regarding implementation. I currently would prefer a wait in the close method. What's your preferred implementation? |
Yeah, a blocking close() would be fine. I guess a simple CountdownLatch in Thanks! |
@MiErnst gentle ping |
I added an additional commit to the pull request. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Calling close on a client instance with default config does not wait for all resources to be closed. Wait means that
ChannelManager.close()
starts an async process (eventLoopGroup.shutdownGracefully...
) but does not wait for the future to be completed.Because it does not wait, the
close
call completes before the async task is completed and my application continues to shutdown while the async task is still running. This results in anIllegalStateException
and lots ofNoClassDefFoundError
s in my application. TheIllegalStateException
is caused because the web application which integrates the ahc is already terminated. TheNoClassDefFoundError
s are caused because the netty threads are still running but the classloader is not able to load the classes anymore. Because there are lots of threads, there are also lots of thisNoClassDefFoundError
s.I miss either a wait till all futures are completed or a close method which provides a future as return value so I can wait for the close.
Current workaround is to call
Thread.sleep
after calling close but this is not a deterministic solution.Also the implementation of
isClosed
is not implemented properly because it returns whether the close has been triggered but not ifclose
has been finished. This should also be improved. A method likeisClosing
may return theAtomicBoolean
close
value.The text was updated successfully, but these errors were encountered: