redlsz opened a new issue, #1327:
URL: https://github.com/apache/rocketmq-clients/issues/1327
### Before Creating the Enhancement Request
- [x] I have confirmed that this should be classified as an enhancement
rather than a bug/feature.
### Programming Language of the Client
Go
### Summary
receiveMessageLater calls receiveMessageImmediatelyWithAttemptId on timer
expiry, skipping the isCacheFull() guard.
```
func (dpq *defaultProcessQueue) receiveMessageLater(duration time.Duration,
attemptId string) {
time.AfterFunc(duration, func() {
defer func() {
if err := recover(); err != nil {
dpq.consumer.cli.log.Errorf("[Bug] Failed to
schedule message receiving request, mq=%s, clientId=%s, err=%v", dpq.mqstr,
dpq.consumer.cli.clientID, err)
dpq.onReceiveMessageException(err, attemptId)
}
}()
dpq.consumer.cli.log.Infof("Try to receive message later,
mq=%s, delay=%v, clientId=%s", dpq.mqstr, duration, dpq.consumer.cli.clientID)
dpq.receiveMessageImmediatelyWithAttemptId(attemptId)
})
}
```
### Motivation
`maxCacheMessageCount` silently fails as a bound. Users who set it to
control memory pressure or processing concurrency get no reliable guarantee.
### Describe the Solution You'd Like
Replace receiveMessageImmediatelyWithAttemptId with
receiveMessageWithAttemptId in the timer callback:
```
// process_queue.go
- dpq.receiveMessageImmediatelyWithAttemptId(attemptId)
+ dpq.receiveMessageWithAttemptId(attemptId)
```
receiveMessageWithAttemptId re-checks isCacheFull() and re-arms the delay
if the cache is still full, matching Java behavior.
### Describe Alternatives You've Considered
/
### Additional Context
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]