> On Oct 5, 2018, at 2:25 PM, Colin McCabe <cmcc...@apache.org> wrote:
>
> t's possible for the change to be 100% backwards compatible, but still not
> have a separate code path for people who don't want to use this feature,
> right? What I am getting at is basically: will this feature increase
> broker-side memory consumption for people who don't use it?
Hi Colin,
My intent is to leave current consumer semantics and performance and resource
characteristics intact. Therefore there should be no additional resources
necessary for existing code paths.
I would expect that a PR would likely not be accepted if there was a
degradation of performance for the existing code paths.
Regarding use-cases, it seems that prioritized topics would be required for
interleaving messages from multiple topics in order of priority. For example,
let’s say each topic represents a real-time news feed (i.e. NY Times,
Washington Post, Boston Globe). And if we’d like to process messages from the
NY Times first as these arrive. This could be expressed easily using topic
prioritization. With multiple consumers the merging and interleaving of
messages would have to be done by the caller. Its certainly doable, though it
seems like those who are requesting topic prioritization are asking for a more
expressive consumer API. My $0.02.
Best,
--
Nick
