[GitHub] [pulsar] sijie edited a comment on issue #4062: Delayed message delivery implementation

[GitBox <gi...@apache.org>]

sijie edited a comment on issue #4062: Delayed message delivery implementation
URL: https://github.com/apache/pulsar/pull/4062#issuecomment-484199134
 
 
   
   > Is that a bad thing? Is there any limitation in this approach?
   > The changes to the dispatcher itself have been isolated in a very few specific points. 
   
   It is not a bad thing. I am actually super happy to see this happen because I am a supporter for broker-side approaches from the beginning (if you have followed the email discussion).
   
   If you took a look at [my comment](https://github.com/apache/pulsar/pull/4062#pullrequestreview-227588319), PIP-26 also isolates the changes to a structure called `DelayedMessageIndex` (which is the structure you called DelayedDeliveryTracker here). So technically there are no fundamental differences between this PR and PIP-26 regarding the concerns around changes touching dispatcher. I am just trying to figure out why and make sure the authors of PIP-26 also understand your thoughts behind this. IMO that is an important thing for building a healthy community.
   
   > The biggest difference with this PR is that the tracking happens entirely off-heap, in direct memory. There are no objects created and retained for extended amount of time, which is the pattern that will kill the GC performances.
   
   I don't think the biggest difference with this PR and PIP-26 is the direct memory thing you mentioned on implementing DelayDeliveryTracker. The delayed message index in PIP-26 can also be implemented using direct memory without allocation. 
   
   IMO the difference between this PR and PIP-26 is - `DelayedDeliveryTracker` in this PR is a pure memory structure which can not hold "delayed index" beyond memory; `DelayedMessageIndex` in PIP-26 is a time partitioned structure which can spool the index back to ledgers.  `DelayedDeliveryTracker` is limited at the delay ranges that it can support. `DelayedMessageIndex` is a more generic approach on supporting arbitrary delays or scheduled messages. 
   
   `DelayedDeliveryTracker` and `DelayedMessageIndex` are just two different implementations of one same things. If the current implementation of `DelayedDeliveryTracker` is acceptable, why the proposal of a time-partitioned `DelayedMessageIndex` is not acceptable? People can choose which implementation to use by configuring a configuration in the broker configuration.
   
   Lastly, PIP-26 already presents changes regarding api, protocol, namespace policies and many other changes around this area. Shall we just pickup the proposed changes there instead of starting a new effort?

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services