-
Notifications
You must be signed in to change notification settings - Fork 609
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
program suspends when destroying an async client in requestError() callback #70
Comments
when I pass the client, a shared_ptr, into callback as a member variable, the problem seems to disappear. Hope that clue will be useful for you guys. |
It seems that when I destroy client in requestError(), thrift will call TAsyncSocket::failAllWrites() which will call requestError(), requestError() has been called recursively. this is why the dead lock occurs. Is it by design? If so, can you guys document it, if not can you improve it? thanks! |
It looks like there might have been an attempt at a fix in this commit: (but was later reverted) 4418d1e Does that solve this issue? |
I am afraid this commit does not solve the problem. Here is the stack trace captured from my test. please note that stack #0 and stack #20, requestError() is called recursively: |
Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed. |
Closing to clean and provide better support to new issues. We are rewriting docs and guides on how to support this. |
In my program, I need to reconnect to the server when request error occurs, then I shall insert the new client into a map shared by several worker threads and the map is locked before insertion. However , I find out that when server has closed the connection and my program suspends at where the client is destructed. At first sight, it may seems like a deadlock, what is strange is that the requestError() is called twice by the same thread, and the first call seems to be not completed and the lock is not released!
please see attachment for a short program to reproduce the problem.
The text was updated successfully, but these errors were encountered: