-
Notifications
You must be signed in to change notification settings - Fork 693
Replace Pub/Sub Subscriber-based implementation with Pull-based #1056
Comments
@meltsufin is the plan to keep the |
We will be able to collapse them. Basic won't be needed anymore because it comes from the constraints of the streaming API. |
Thoughts on introducing The asynchronous These really don't apply to usage of the |
We were thinking of just replacing the We can also just add Regardless of that, I think we need to change |
That's what I was talking in the beginning: the The Does it make sense? |
@artembilan agreed. |
Makes sense to me too. @elefeint is planning to start work on this later this quarter. |
@artembilan @meltsufin what do you think about the plan below? Part I, make it easy to bypass PubSub async pull's message hoarding behavior when using GCP-to-SpringIntegration and GCP-to-CloudStream integrations.
Part II, simplify
|
No, you can't extend The This way you won't need to rename I'm not sure what is that On the other hand we are now in the GA phase, so we have to be careful what we are going to break. or just deffer such a work for the next Thanks for understanding! |
Let me see if I understand... with numbered topics for future reference; threading in github is a challenge:
Non-critical-path conversation:
|
That's not correct to make such a critical change for that Everything else sounds good. |
Pub/Sub streaming subscriber API is currently not well suited for low QPS applications.
See #984 for more context.
See docs for an explanation.
cc: @kir-titievsky
The text was updated successfully, but these errors were encountered: