Open h27771420 opened 1 week ago
Ack; we've considered this before (https://github.com/google/go-cloud/issues/3507).
@vangent Ahhhhh, thanks for your response, I guess you mean https://github.com/google/go-cloud/issues/3130? And that AckID
should be abled to invoke ModifyAckDeadline.
I saw the reason, but in my case, it feels weird to open another google/pubsub
client to make this request.
It is like opening the Pub/Sub
client twice at the same time, I really don't like to do that. 😔
Or could it be an option in pubsub/gcppubsub
to decide whether to automatically extend Ack deadline, or let the Subscription client extend a specific time for Ack deadline?
(e.g., A MaxExtension
option in google/pubsub
https://github.com/googleapis/google-cloud-go/issues/608)
For go-cloud
, maybe
url := "gcppubsub://...?MaxExtension=3000" // sec
You can certainly do this with As
.
pubsub.Subscription.As()
will get you a SubscriberClient (https://github.com/google/go-cloud/blob/master/pubsub/gcppubsub/gcppubsub.go#L45)pubsub.Message.As()
will get you a pb.ReceivedMessage
(https://github.com/google/go-cloud/blob/master/pubsub/gcppubsub/gcppubsub.go#L48) which contains the AckID
in it.ModifyAckDeadline
. It's not opening another client.gcppubsub
provider to support automatically extending ack deadlines, similar to what the higher-level GCP pubsub client does (there are references in #3507). It doesn't look like this functionality makes sense for pubsub
as a whole, but it might be reasonable for the GCP pubsub provider specifically. I will consider it; in the meantime if you're stuck you can do this yourself as described above.Awesome, thanks for pointing out the pubsub.Subscription.As()
, I think this could be quite elegant.
- pubsub.Subscription.As() will get you a SubscriberClient (https://github.com/google/go-cloud/blob/master/pubsub/gcppubsub/gcppubsub.go#L45)
Is your feature request related to a problem? Please describe.
I guess I have to start with the differences between AWS SQS and GCP Pub/Sub, here are what I think are the more significant differences between them
Ack
queue message after thevisibility timeout
is exceeded.Ack Deadline
is exceeded, ourAck
operation will fail.visibility timeout
of SQS is 12 hours.Ack deadline
of Pub/Sub is 10 minutes.So here is my current situation, I'm migrating our library from the AWS SDK to go-cloud to invoke Pub/Sub. (Eventually I would like to make it works like a
multi-cloud
/multi-queue-service
support.) (Btw, I really have to say, go-cloud is truly amazing. 😄 ) But, the design logic in all my previous services was basically Queue-message-driven. I usually poll the message first and then start processing the message. When the processing is completed, I would decide whether toAck
orNack
.I know that though they are essentially different services, the above differences are too huge, so when processing some time-consuming requests, 10 minutes is often not enough. (Pub/Sub also not allow us to
Ack
after reached the deadline. 😔 ) In the end my service usually can handle that message successfully, but because that message cannot be correctlyAck
ed, that message will be judged as a processing failure by Pub/Sub, and will eventually be automatically transferred to the dead letter topic.Describe the solution you'd like
So I hope
go-cloud
can add a new method to extendAck deadline
.Describe alternatives you've considered
The alternative I guess would be For polling:
For handling:
(However, there is still a problem. If it
panic
, the whole thing will be ruined, so another thing may be needed to provide to prevent that request from disappearing forever afterpanic
ing.)Additional context
Sorry, I seem to have written context in the wrong place, please refer to above.