frankly speaking, I am not sure about the producer concerns: producer memory, authorization, and schema. if you model DLQ topic as replicating messages whose delivery count is larger than max-delivery-count, it should be no difference than cross-data-center replication.
but anyway, since there are two strong opinions on doing this at client-side. I am fine with doing publish at client side. just keep one thing in mind, this feature might end up never happening at some of the languages (for example, websocket) unless there are efforts spent on this. --- Let me summarize the discussion in this PR to make sure everyone is on same page about the scope of this PR. The suggestion for the implementation will be: - keep the delivery count tracking still at broker - move the publish to DLQ logic to consumer side for other comments from Matteo will not be included in PR. but will be done via future improvements: - negative acks would be an independent feature in future. this PR doesn't have to deal with that. - message retention will not be enforced in this PR. Applications will be responsible for setting correct message retention. Documentation will be added to make things clear. We can enforce DLQ topic rentention when we allow overriding policies at topic/subscription level. @merlimat @rdhabalia can you confirm the summary is correct? @codelipenghui does this approach work for your application? [ Full content available at: https://github.com/apache/incubator-pulsar/pull/2400 ] This message was relayed via gitbox.apache.org for [email protected]
