joefk commented on issue #4062: Delayed message delivery implementation URL: https://github.com/apache/pulsar/pull/4062#issuecomment-484105300 >The changes to the dispatcher itself have been isolated in a very few specific points. It should be easy to review and verify that with feature turned off there's zero impact in current behavior. Nice to see that change, is there a config option to turn it off per namespace? > A topic will have ByteBuf using direct memory where the priority queue is stored. On the data path there are no other allocations required. How does this work with load balancing? Does the load balancer know which topics are going to need this allocation. Is there a limit on delay, num of delayed messages pending etc? What's the limits? How is inversion handled? What happens if a message to be delayed by for eg: a few days is at the head? Will that halt the advance of the delete cursor? What if a few of those kind are randomly spread around? Is this taking for granted that on a broker restart, everything spanning the period of largest delay will potentially be read through again? Is there a checkpoint for a polite shutdown/unload? I prefer configurable limits, and deterministic performance so that system behavior can be predicted during rolling upgrades and failures. Pulsar handles rolling upgrades and failures way better than other systems , and it would be preferable to maintain that.
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
