sijie commented 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 seeing this happening 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:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to