AwaitableUnaryClientCallListener still holds lock after onMessage

Question

AwaitableUnaryClientCallListener still holds lock after onMessage

meltsufin opened this issue 6 years ago · 7 comments

Contrary to the javadoc on AwaitableUnaryClientCallListener that says Blocks until {@link #onMessage} or {@link #onClose}., it continues blocking after onMessage until onClose is called.

Potentially related to: spring-attic/spring-cloud-gcp#1118 where we're seeing hanging threads.

Answer 1 · 2018-10-29T00:56:37.000Z

agreed. the next task is to figure out why awaiting until a status was received is a problem

Answer 2 · 2018-10-29T00:59:16.000Z

Thanks for reporting the doc bug. Feel free to open another issue if there's a new behavior we need to be aware of, or if there is a condition which escapes the onClose callback.

Answer 3 · 2018-10-29T13:36:44.000Z

Thanks for fixing the doc. What do you think of having a timeout when waiting on the count-down-latch?

Answer 4 · 2018-10-30T00:47:13.000Z

well, it sounds like working around a state bug :P

…

On Mon, Oct 29, 2018 at 10:36 PM Mike Eltsufin ***@***.***> wrote: Thanks for fixing the doc. What do you think of having a timeout when waiting on the count-down-latch? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#100 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD611csp0zBsmOChcHExHyiF0S6W7noks5upwRxgaJpZM4X4Qvq> .

Answer 5 · 2018-10-30T00:49:28.000Z

I guess what I mean to say is if there is a state bug, then if we add a timeout, whereever the exposure to that bug is would be possible to hit that timeout on each request. In your setup can you verify that netty, etc is aligned properly? Wondering where the cases are that the finish hook might not be called as that seems something that would affect others... perhaps there's a missing try/finally somewhere?

…

Answer 6 · 2018-10-30T14:47:04.000Z

You can see some results of the investigation here: spring-attic/spring-cloud-gcp#1118.
I'm still not sure why it would ever be better to wait indefinitely than some specified timeout. Waiting indefinitely just masks the problem longer, whereas a failure at timeout at least gives an earlier indication that something is wrong.

Answer 7 · 2018-10-30T23:16:02.000Z

If you want to raise a pull request, trap the timeout exception and throw as an IllegalStateException saying something like possible bug, that could make sense cc @anuraaga

…

On Tue, Oct 30, 2018 at 11:49 PM Mike Eltsufin ***@***.***> wrote: You can see some results of the investigation here: spring-attic/spring-cloud-gcp#1118 <spring-attic/spring-cloud-gcp#1118>. I'm still not sure why it would ever be better to wait indefinitely than some specified timeout. Waiting indefinitely just masks the problem longer, whereas a failure at timeout at least gives an earlier indication that something is wrong. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#100 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD61zWFIC7izTcecWHstf-ukiHxn_S3ks5uqGbqgaJpZM4X4Qvq> .