-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
subscription pull deadline exceeded #2574
Comments
Thanks for reporting @mwytock! Unless I'm missing some context, this seems like it could be the correct reaction in certain scenarios?
See: https://cloud.google.com/pubsub/docs/error-codes There is talk of adding retry logic to the client but that hasn't been done yet. There are some pretty good libraries out there for retrying. |
well, the previous behavior was that it would wait for awhile and then if you do actually want to throw an exception here, you should throw On Thu, Oct 20, 2016 at 7:32 AM, Thomas Schultz notifications@github.com
|
When you say "before", do you remember what version of the library you were using for that behavior? I don't think much has changed with pubsub in a while so that would a place I could start looking. Usually we catch and rethrow exceptions when the gRPC ones don't say much about what happened. In this case it actually seems like a decent message. |
in my case "before" was using a version that did not default to the grpc implementation 0.18.X in my opinion its weird to have to deal with this exception in a fairly standard use case (subscription empty), but if this is the intended behavior so be it |
@mwytock This isn't the intended behavior. So far we've tried to catch gRPC errors and re-wrap them as standard ones from our FWIW, this would still have thrown an exception, since it's really just a timeout on the backend (though we don't yet have a Is this exception happening on a regular basis or just some of the time? |
My bad, I thought there were only special cases that we wanted to catch and reraise from gRPC. |
great, that makes sense it seems to happen just about every time I call sub.pull() and there are no messages available in this subscription. im guessing whats happening behind the scenes is the rpc is sitting and waiting and hits the deadline before any messages arrive. this seemed to work more cleanly in the previous non-grpc world for now, i just used the simple workaround pulled = sub.pull(return_immediately=True)
if not pulled:
time.sleep(args.pubsub_empty_delay) this subscription has an ack deadline of 60 seconds, not sure if that effects setting of rpc deadlines, etc. |
Calling
sub.pull()
sometimes results in deadline exceeded exceptions from lower layer, I believe when the topic is empty.The text was updated successfully, but these errors were encountered: