+1 for adding init_subscription filed to the metadata of CommandProducer.
On Thu, Jan 20, 2022 at 2:52 PM PengHui Li <peng...@apache.org> wrote: > > > What is the justification for avoiding the new protobuf field? If we > add a structured field to a map of <String, String>, we are still > modifying the protocol, even if we aren't modifying the protobuf. > > Not all cases need a new field named init_subscription when creating > producer, > and users will not touch the metadata of the producer of a DLQ, so I think > we can use the metadata to achieve the purpose more flexibly. > > Yes, it modifies the protocol, but in different ways. It like the message > properties, > we also introduce some system message properties such as > __original_message_id > in retry letter topic. > > Penghui > > On Thu, Jan 20, 2022 at 2:05 PM Michael Marshall <mmarsh...@apache.org> > wrote: > > > > I think that, good or bad, the impression that users have that the DLQ > > > is not a "normal" topic > > > > Thanks for your perspective, Matteo. I still prefer my alternative > > design that bypasses subscription creation, but it seems there > > is insufficient interest in it, so we should move forward > > discussing a DLQ specific feature and its implementation. > > > > > 1. Instead of modifying the current protocol, we can use producer > > > metadata to carry the init subscription > > > > What is the justification for avoiding the new protobuf field? If we > > add a structured field to a map of <String, String>, we are still > > modifying the protocol, even if we aren't modifying the protobuf. > > > > Thanks, > > Michael > > > > > > On Tue, Jan 18, 2022 at 8:38 AM PengHui Li <peng...@apache.org> wrote: > > > > > > +1 for adding the DLQ_init_sub to producer metadata so that we don't > > > need to introduce a new field in CommandProducer, and the new field > > > looks a little confusing > > > > > > Thanks, > > > Penghui > > > > > > On Mon, Jan 17, 2022 at 10:19 PM Hang Chen <chenh...@apache.org> wrote: > > > > > > > Thanks for creating this proposal Zike Yang. I have two ideas about it. > > > > 1. Instead of modifying the current protocol, we can use producer > > > > metadata to carry the init subscription > > > > 2. Please add auth for subscription creation when create topic by > > > > producer, otherwise, it will be easily attacked. > > > > > > > > Thanks, > > > > Hang > > > > > > > > Matteo Merli <matteo.me...@gmail.com> 于2022年1月12日周三 15:13写道： > > > > > > > > > > > If we want to hold that the DLQ is not a normal topic, then I can > > see > > > > > > why we would have a DLQ specific feature here. > > > > > > > > > > I think that, good or bad, the impression that users have that the > > DLQ > > > > > is not a "normal" topic comes from 2 factors: > > > > > 1. The experience with traditional messaging systems JMS and others > > > > > where the DLQ are handled in slightly different ways, compared to > > > > > other topics > > > > > 2. The name "DLQ" which in a way it's implying a "queue"... which > > can > > > > > be implemented on topic, using a subscription.. > > > > > > -- Zike Yang
