xdkxlk commented on PR #5387: URL: https://github.com/apache/rocketmq/pull/5387#issuecomment-1294416329
> > > > > > > > > > > > We can use an in-memory timer to record the time at which the lock is released. When the time is up, check to see if there is a message that can be pulled and if so, wake up the pending long polling request. > > > > > > > > > I do not see the reason why an in-memory timer is required. Once a previous pop request that holds the lock completes, why not simply dispatch a task to check if there is an await pop request held in the chain... On the completion of on request, fire a second in consecutive. > > > > > > For example: If we pop one message orderly (invisible time is 5s) and not ack this message, we expect re-consume this message 5s later. Then we send a new pop request with the 30s long polling timeout. If wait this request timeout, the message will delay 25s to be re-consumed, so we need a timer to wake up this long polling request after 5s. > > I mean, in your given example, can the state change(timeout of the popped message) itself act as the trigger? Not like pop normally, there isn't a timed ck message for pop orderly If we change the state of popped message to a timed message, we still need a in-memory buffer to prevent there are too many timed message needed put into store, like PopBufferMergeService Meanwhile for pop orderly, the locking time is generally not very long, so the in-memory timer is enough -- 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]
