apache / apache/pulsar-client-go
nack backoff policy may not be used
- Dominant language
- Go
- Stars
- 745
- Forks
- 389
- Avg merge
- 3d 20h
- Merged PRs (30d)
- 3
Description
In PIP-106 and #660, the Pulsar SDK for Golang has supported `NackBackoffPolicy`. However, using a topic with 1 partition, the following code may not use the backoff policy:
```go
polarisConsumer := p.consumers[priority], err = client.Subscribe(pulsar.ConsumerOptions{
Topic: "demoTopic",
SubscriptionName: "demoSubscriptionName",
Type: pulsar.Shared,
RetryEnable: true,
DLQ: &pulsar.DLQPolicy{
MaxDeliveries: 10,
},
EnableDefaultNackBackoffPolicy: true,
})
msg := <-polarisConsumer.Chan()
msg.Nack(msg)
```
After some digging I found the following call stack:
- `Nack` for a message is implemented in [`pulsar/consumer_impl.go`](https://github.com/apache/pulsar-client-go/blob/master/pulsar/consumer_impl.go#L517), it may call the consumer carried by a `trackingMessageID`
- `trackingMessageID` defined `Nack()` at [`pulsar/impl_message.go`](https://github.com/apache/pulsar-client-go/blob/master/pulsar/impl_message.go#L78), calling `NackID()`
- `NackID()` is implemented at [`pulsar/consumer_partition.go`](https://github.com/apache/pulsar-client-go/blob/master/pulsar/consumer_partition.go#L341), calling `Add()` method for the nack tracker.
And in the implementation of [`Add()`](https://github.com/apache/pulsar-client-go/blob/master/pulsar/negative_acks_tracker.go#L68) method, it's obviously impossible to use the back off policy, since redeliver count is not available, so default back off delay is used.
I'm not sure if my code is using the back off policy in the right way, or this is a bug in the SDK, or our broker is having some issue.
Contributor guide
Research direction
Reproduce the one-partition setup, then trace Nack in pulsar/consumer_impl.go through pulsar/impl_message.go and pulsar/consumer_partition.go to negative_acks_tracker.go. Check whether Add receives enough redelivery information to apply NackBackoffPolicy; done means the expected backoff behavior is confirmed or the defect is documented with a focused regression test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100