-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
com.google.cloud.pubsub.v1.Subscriber how to await stop signal? #2485
Comments
@peter-gerhard You're not doing anything wrong. The The exception isn't actually thrown from |
Hello @pongad, thx for the reply.
Exactly.
Thats what it looked like to me. It doesn't do anything bad but the output mixed with my test logs and it was confusing since the error suggests a high severity. Thx for taking care. |
In the doc, we just wait for done.get() to return before closing the Subscriber. This commit makes clear that done.get() in the doc is an example condition. Updates #2485.
We register a callback to reconnect connection when old connection closes. When we shut down the subscriber, we close all connections and begin to shutdown executor. There is a race: if the callback is called after executor closes, an exception occurs and we print a scary stack trace. It doesn't do anything bad; the subscriber is going to go away anyway, but the stack trace is still confusing. This commit avoids registering new jobs on executors. When a connection closes, the callback to determine whether we should reconnect is called in the RPC thread. If the connection closes due to some error, the callback should quickly determine whether we should reconnection. If so, we register the actual reconnection job on a separate thread. This does not block RPC thread, and everyone should be happy. If the connection closes because we're shutting down, the callback running on RPC thread should determine that we should NOT reconnect, not register a reconnection job, and we shouldn't see a stack trace. Fixes #2485.
In the doc, we just wait for done.get() to return before closing the Subscriber. This commit makes clear that done.get() in the doc is an example condition. Updates googleapis#2485.
We register a callback to reconnect connection when old connection closes. When we shut down the subscriber, we close all connections and begin to shutdown executor. There is a race: if the callback is called after executor closes, an exception occurs and we print a scary stack trace. It doesn't do anything bad; the subscriber is going to go away anyway, but the stack trace is still confusing. This commit avoids registering new jobs on executors. When a connection closes, the callback to determine whether we should reconnect is called in the RPC thread. If the connection closes due to some error, the callback should quickly determine whether we should reconnection. If so, we register the actual reconnection job on a separate thread. This does not block RPC thread, and everyone should be happy. If the connection closes because we're shutting down, the callback running on RPC thread should determine that we should NOT reconnect, not register a reconnection job, and we shouldn't see a stack trace. Fixes googleapis#2485.
Hi,
when im calling
stopAsync
on a subscriber i get the following exception:the doc of the
startAsync
suggests to wait for a stop signal:But i don't know what is meant by
done.get();
version 0.25.0-beta
The text was updated successfully, but these errors were encountered: