pulsar-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [pulsar] joefk edited a comment on issue #4062: Delayed message delivery implementation
Date Wed, 17 Apr 2019 14:15:44 GMT
joefk edited a comment 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 ON 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:

With regards,
Apache Git Services

View raw message