Re: [DISCUSS] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
Thanks for the KIP. I was initially wondering if we need to add this into Kafka code base not. You could just go with a custom `Partitioner` implementation. The demand of KAFKA- seems not to be big actually. On the other hand, it might be a generic use case that justifies to add to Kafka code base. Also, it's not much code and thus easy to maintain. About naming: `RoundRobinPartitioner` seems to be a good name. `KeylessPartitioner` does not describe how partitions are selected. I don't see any conflict with `DefaultPartitioner` -- it implements a hybrid strategy depending if key is `null` or not (thus finding a name better than `DefaultPartitioner` that describes the strategy seem to be difficult). Feel free to start a VOTE :) I don't expect this KIP to be controversial. -Matthias On 9/2/18 7:57 AM, M. Manna wrote: > Thanks for all your comments and taking it easy on me for my first KIP :) > > I am trying to check if it's okay for us to start a vote on this? As per > some recent comment I'll change the name to RoundRobinPartitioner. > > I'll need to put some effort in writing Scala tests etc. since I'm a novice > with Scala. > > Please let me know your thoughts, and I'll update the status accordingly > (and start working on the JIRA once it's approved). > > Regards, > > On Fri, 31 Aug 2018, 10:22 M. Manna, wrote: > >> Yes I’m more than happy to change it to a more appropriate name. >> >> The issue with RoundRobinPatitoner is that the DefaultPartitioner already >> has a Round-Robin associated to it. But if community doesn’t mind the name, >> I don’t either. >> >> Thanks for reading the KIP btw. >> >> Regards, >> >> On Fri, 31 Aug 2018 at 05:47, Magesh Nandakumar >> wrote: >> >>> +1 for this. The only small suggestion would be to possibly call this >>> RondRobinPartitioner which makes the intent obvious. >>> >>> On Thu, Aug 30, 2018 at 5:31 PM Stephen Powis >>> wrote: >>> Neat, this would be super helpful! I submitted this ages ago: https://issues.apache.org/jira/browse/KAFKA- On Fri, Aug 31, 2018 at 5:04 AM, Satish Duggana < >>> satish.dugg...@gmail.com> wrote: > +including both dev and user mailing lists. > > Hi, > Thanks for the KIP. > > "* For us, the message keys represent some metadata which we use to either > ignore messages (if a loop-back to the sender), or log some information.*" > > Above statement was mentioned in the KIP about how key value is used. >>> I > guess the topic is not configured to be compacted and you do not want >>> to > have partitioning based on that key. IMHO, it qualifies more as a >>> header > than a key. What do you think about building records with a specific header > and consumers to execute the logic whether to process or ignore the > messages based on that header value. > > Thanks, > Satish. > > > On Fri, Aug 31, 2018 at 1:32 AM, Satish Duggana < satish.dugg...@gmail.com> > wrote: > >> Hi, >> Thanks for the KIP. >> >> "* For us, the message keys represent some metadata which we use to >> either ignore messages (if a loop-back to the sender), or log some >> information.*" >> >> Above statement was mentioned in the KIP about how key value is >>> used. I >> guess the topic is not configured to be compacted and you do not >>> want to >> have partitioning based on that key. IMHO, it qualifies more as a header >> than a key. What do you think about building records with a specific > header >> and consumers to execute the logic whether to process or ignore the >> messages based on that header value. >> >> Thanks, >> Satish. >> >> >> On Fri, Aug 31, 2018 at 12:02 AM, M. Manna >>> wrote: >> >>> Hi Harsha, >>> >>> thanks for reading the KIP. >>> >>> The intent is to use the DefaultPartitioner logic for round-robin >>> selection >>> of partition regardless of key type. >>> >>> Implementing Partitioner interface isn’t the issue here, you would have > to >>> do that anyway if you are implementing your own. But we also want this > to >>> be part of formal codebase. >>> >>> Regards, >>> >>> On Thu, 30 Aug 2018 at 16:58, Harsha wrote: >>> Hi, Thanks for the KIP. I am trying to understand the intent of the KIP. Is the use case you specified can't be achieved by implementing >>> the Partitioner interface here? https://github.com/apache/kafka/blob/trunk/clients/src/main/ >>> java/org/apache/kafka/clients/producer/Partitioner.java#L28 . Use your custom partitioner to be configured in your producer clients. Thanks, Harsha On Thu, Aug 30, 2018, at 1:45 AM, M. Manna wrote: > Hello, > > I opened a
Re: [DISCUSS] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
Thanks for all your comments and taking it easy on me for my first KIP :) I am trying to check if it's okay for us to start a vote on this? As per some recent comment I'll change the name to RoundRobinPartitioner. I'll need to put some effort in writing Scala tests etc. since I'm a novice with Scala. Please let me know your thoughts, and I'll update the status accordingly (and start working on the JIRA once it's approved). Regards, On Fri, 31 Aug 2018, 10:22 M. Manna, wrote: > Yes I’m more than happy to change it to a more appropriate name. > > The issue with RoundRobinPatitoner is that the DefaultPartitioner already > has a Round-Robin associated to it. But if community doesn’t mind the name, > I don’t either. > > Thanks for reading the KIP btw. > > Regards, > > On Fri, 31 Aug 2018 at 05:47, Magesh Nandakumar > wrote: > >> +1 for this. The only small suggestion would be to possibly call this >> RondRobinPartitioner which makes the intent obvious. >> >> On Thu, Aug 30, 2018 at 5:31 PM Stephen Powis >> wrote: >> >> > Neat, this would be super helpful! I submitted this ages ago: >> > https://issues.apache.org/jira/browse/KAFKA- >> > >> > On Fri, Aug 31, 2018 at 5:04 AM, Satish Duggana < >> satish.dugg...@gmail.com> >> > wrote: >> > >> > > +including both dev and user mailing lists. >> > > >> > > Hi, >> > > Thanks for the KIP. >> > > >> > > "* For us, the message keys represent some metadata which we use to >> > either >> > > ignore messages (if a loop-back to the sender), or log some >> > information.*" >> > > >> > > Above statement was mentioned in the KIP about how key value is used. >> I >> > > guess the topic is not configured to be compacted and you do not want >> to >> > > have partitioning based on that key. IMHO, it qualifies more as a >> header >> > > than a key. What do you think about building records with a specific >> > header >> > > and consumers to execute the logic whether to process or ignore the >> > > messages based on that header value. >> > > >> > > Thanks, >> > > Satish. >> > > >> > > >> > > On Fri, Aug 31, 2018 at 1:32 AM, Satish Duggana < >> > satish.dugg...@gmail.com> >> > > wrote: >> > > >> > > > Hi, >> > > > Thanks for the KIP. >> > > > >> > > > "* For us, the message keys represent some metadata which we use to >> > > > either ignore messages (if a loop-back to the sender), or log some >> > > > information.*" >> > > > >> > > > Above statement was mentioned in the KIP about how key value is >> used. I >> > > > guess the topic is not configured to be compacted and you do not >> want >> > to >> > > > have partitioning based on that key. IMHO, it qualifies more as a >> > header >> > > > than a key. What do you think about building records with a specific >> > > header >> > > > and consumers to execute the logic whether to process or ignore the >> > > > messages based on that header value. >> > > > >> > > > Thanks, >> > > > Satish. >> > > > >> > > > >> > > > On Fri, Aug 31, 2018 at 12:02 AM, M. Manna >> wrote: >> > > > >> > > >> Hi Harsha, >> > > >> >> > > >> thanks for reading the KIP. >> > > >> >> > > >> The intent is to use the DefaultPartitioner logic for round-robin >> > > >> selection >> > > >> of partition regardless of key type. >> > > >> >> > > >> Implementing Partitioner interface isn’t the issue here, you would >> > have >> > > to >> > > >> do that anyway if you are implementing your own. But we also want >> > this >> > > to >> > > >> be part of formal codebase. >> > > >> >> > > >> Regards, >> > > >> >> > > >> On Thu, 30 Aug 2018 at 16:58, Harsha wrote: >> > > >> >> > > >> > Hi, >> > > >> > Thanks for the KIP. I am trying to understand the intent of >> > the >> > > >> > KIP. Is the use case you specified can't be achieved by >> > implementing >> > > >> the >> > > >> > Partitioner interface here? >> > > >> > https://github.com/apache/kafka/blob/trunk/clients/src/main/ >> > > >> java/org/apache/kafka/clients/producer/Partitioner.java#L28 >> > > >> > . >> > > >> > Use your custom partitioner to be configured in your producer >> > clients. >> > > >> > >> > > >> > Thanks, >> > > >> > Harsha >> > > >> > >> > > >> > On Thu, Aug 30, 2018, at 1:45 AM, M. Manna wrote: >> > > >> > > Hello, >> > > >> > > >> > > >> > > I opened a very simple KIP and there exists a JIRA for it. >> > > >> > > >> > > >> > > I would be grateful if any comments are available for action. >> > > >> > > >> > > >> > > Regards, >> > > >> > >> > > >> >> > > > >> > > > >> > > >> > >> >
Re: [DISCUSS] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
Yes I’m more than happy to change it to a more appropriate name. The issue with RoundRobinPatitoner is that the DefaultPartitioner already has a Round-Robin associated to it. But if community doesn’t mind the name, I don’t either. Thanks for reading the KIP btw. Regards, On Fri, 31 Aug 2018 at 05:47, Magesh Nandakumar wrote: > +1 for this. The only small suggestion would be to possibly call this > RondRobinPartitioner which makes the intent obvious. > > On Thu, Aug 30, 2018 at 5:31 PM Stephen Powis > wrote: > > > Neat, this would be super helpful! I submitted this ages ago: > > https://issues.apache.org/jira/browse/KAFKA- > > > > On Fri, Aug 31, 2018 at 5:04 AM, Satish Duggana < > satish.dugg...@gmail.com> > > wrote: > > > > > +including both dev and user mailing lists. > > > > > > Hi, > > > Thanks for the KIP. > > > > > > "* For us, the message keys represent some metadata which we use to > > either > > > ignore messages (if a loop-back to the sender), or log some > > information.*" > > > > > > Above statement was mentioned in the KIP about how key value is used. I > > > guess the topic is not configured to be compacted and you do not want > to > > > have partitioning based on that key. IMHO, it qualifies more as a > header > > > than a key. What do you think about building records with a specific > > header > > > and consumers to execute the logic whether to process or ignore the > > > messages based on that header value. > > > > > > Thanks, > > > Satish. > > > > > > > > > On Fri, Aug 31, 2018 at 1:32 AM, Satish Duggana < > > satish.dugg...@gmail.com> > > > wrote: > > > > > > > Hi, > > > > Thanks for the KIP. > > > > > > > > "* For us, the message keys represent some metadata which we use to > > > > either ignore messages (if a loop-back to the sender), or log some > > > > information.*" > > > > > > > > Above statement was mentioned in the KIP about how key value is > used. I > > > > guess the topic is not configured to be compacted and you do not want > > to > > > > have partitioning based on that key. IMHO, it qualifies more as a > > header > > > > than a key. What do you think about building records with a specific > > > header > > > > and consumers to execute the logic whether to process or ignore the > > > > messages based on that header value. > > > > > > > > Thanks, > > > > Satish. > > > > > > > > > > > > On Fri, Aug 31, 2018 at 12:02 AM, M. Manna > wrote: > > > > > > > >> Hi Harsha, > > > >> > > > >> thanks for reading the KIP. > > > >> > > > >> The intent is to use the DefaultPartitioner logic for round-robin > > > >> selection > > > >> of partition regardless of key type. > > > >> > > > >> Implementing Partitioner interface isn’t the issue here, you would > > have > > > to > > > >> do that anyway if you are implementing your own. But we also want > > this > > > to > > > >> be part of formal codebase. > > > >> > > > >> Regards, > > > >> > > > >> On Thu, 30 Aug 2018 at 16:58, Harsha wrote: > > > >> > > > >> > Hi, > > > >> > Thanks for the KIP. I am trying to understand the intent of > > the > > > >> > KIP. Is the use case you specified can't be achieved by > > implementing > > > >> the > > > >> > Partitioner interface here? > > > >> > https://github.com/apache/kafka/blob/trunk/clients/src/main/ > > > >> java/org/apache/kafka/clients/producer/Partitioner.java#L28 > > > >> > . > > > >> > Use your custom partitioner to be configured in your producer > > clients. > > > >> > > > > >> > Thanks, > > > >> > Harsha > > > >> > > > > >> > On Thu, Aug 30, 2018, at 1:45 AM, M. Manna wrote: > > > >> > > Hello, > > > >> > > > > > >> > > I opened a very simple KIP and there exists a JIRA for it. > > > >> > > > > > >> > > I would be grateful if any comments are available for action. > > > >> > > > > > >> > > Regards, > > > >> > > > > >> > > > > > > > > > > > > > >
Re: [DISCUSS] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
+1 for this. The only small suggestion would be to possibly call this RondRobinPartitioner which makes the intent obvious. On Thu, Aug 30, 2018 at 5:31 PM Stephen Powis wrote: > Neat, this would be super helpful! I submitted this ages ago: > https://issues.apache.org/jira/browse/KAFKA- > > On Fri, Aug 31, 2018 at 5:04 AM, Satish Duggana > wrote: > > > +including both dev and user mailing lists. > > > > Hi, > > Thanks for the KIP. > > > > "* For us, the message keys represent some metadata which we use to > either > > ignore messages (if a loop-back to the sender), or log some > information.*" > > > > Above statement was mentioned in the KIP about how key value is used. I > > guess the topic is not configured to be compacted and you do not want to > > have partitioning based on that key. IMHO, it qualifies more as a header > > than a key. What do you think about building records with a specific > header > > and consumers to execute the logic whether to process or ignore the > > messages based on that header value. > > > > Thanks, > > Satish. > > > > > > On Fri, Aug 31, 2018 at 1:32 AM, Satish Duggana < > satish.dugg...@gmail.com> > > wrote: > > > > > Hi, > > > Thanks for the KIP. > > > > > > "* For us, the message keys represent some metadata which we use to > > > either ignore messages (if a loop-back to the sender), or log some > > > information.*" > > > > > > Above statement was mentioned in the KIP about how key value is used. I > > > guess the topic is not configured to be compacted and you do not want > to > > > have partitioning based on that key. IMHO, it qualifies more as a > header > > > than a key. What do you think about building records with a specific > > header > > > and consumers to execute the logic whether to process or ignore the > > > messages based on that header value. > > > > > > Thanks, > > > Satish. > > > > > > > > > On Fri, Aug 31, 2018 at 12:02 AM, M. Manna wrote: > > > > > >> Hi Harsha, > > >> > > >> thanks for reading the KIP. > > >> > > >> The intent is to use the DefaultPartitioner logic for round-robin > > >> selection > > >> of partition regardless of key type. > > >> > > >> Implementing Partitioner interface isn’t the issue here, you would > have > > to > > >> do that anyway if you are implementing your own. But we also want > this > > to > > >> be part of formal codebase. > > >> > > >> Regards, > > >> > > >> On Thu, 30 Aug 2018 at 16:58, Harsha wrote: > > >> > > >> > Hi, > > >> > Thanks for the KIP. I am trying to understand the intent of > the > > >> > KIP. Is the use case you specified can't be achieved by > implementing > > >> the > > >> > Partitioner interface here? > > >> > https://github.com/apache/kafka/blob/trunk/clients/src/main/ > > >> java/org/apache/kafka/clients/producer/Partitioner.java#L28 > > >> > . > > >> > Use your custom partitioner to be configured in your producer > clients. > > >> > > > >> > Thanks, > > >> > Harsha > > >> > > > >> > On Thu, Aug 30, 2018, at 1:45 AM, M. Manna wrote: > > >> > > Hello, > > >> > > > > >> > > I opened a very simple KIP and there exists a JIRA for it. > > >> > > > > >> > > I would be grateful if any comments are available for action. > > >> > > > > >> > > Regards, > > >> > > > >> > > > > > > > > >
Re: [DISCUSS] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
Neat, this would be super helpful! I submitted this ages ago: https://issues.apache.org/jira/browse/KAFKA- On Fri, Aug 31, 2018 at 5:04 AM, Satish Duggana wrote: > +including both dev and user mailing lists. > > Hi, > Thanks for the KIP. > > "* For us, the message keys represent some metadata which we use to either > ignore messages (if a loop-back to the sender), or log some information.*" > > Above statement was mentioned in the KIP about how key value is used. I > guess the topic is not configured to be compacted and you do not want to > have partitioning based on that key. IMHO, it qualifies more as a header > than a key. What do you think about building records with a specific header > and consumers to execute the logic whether to process or ignore the > messages based on that header value. > > Thanks, > Satish. > > > On Fri, Aug 31, 2018 at 1:32 AM, Satish Duggana > wrote: > > > Hi, > > Thanks for the KIP. > > > > "* For us, the message keys represent some metadata which we use to > > either ignore messages (if a loop-back to the sender), or log some > > information.*" > > > > Above statement was mentioned in the KIP about how key value is used. I > > guess the topic is not configured to be compacted and you do not want to > > have partitioning based on that key. IMHO, it qualifies more as a header > > than a key. What do you think about building records with a specific > header > > and consumers to execute the logic whether to process or ignore the > > messages based on that header value. > > > > Thanks, > > Satish. > > > > > > On Fri, Aug 31, 2018 at 12:02 AM, M. Manna wrote: > > > >> Hi Harsha, > >> > >> thanks for reading the KIP. > >> > >> The intent is to use the DefaultPartitioner logic for round-robin > >> selection > >> of partition regardless of key type. > >> > >> Implementing Partitioner interface isn’t the issue here, you would have > to > >> do that anyway if you are implementing your own. But we also want this > to > >> be part of formal codebase. > >> > >> Regards, > >> > >> On Thu, 30 Aug 2018 at 16:58, Harsha wrote: > >> > >> > Hi, > >> > Thanks for the KIP. I am trying to understand the intent of the > >> > KIP. Is the use case you specified can't be achieved by implementing > >> the > >> > Partitioner interface here? > >> > https://github.com/apache/kafka/blob/trunk/clients/src/main/ > >> java/org/apache/kafka/clients/producer/Partitioner.java#L28 > >> > . > >> > Use your custom partitioner to be configured in your producer clients. > >> > > >> > Thanks, > >> > Harsha > >> > > >> > On Thu, Aug 30, 2018, at 1:45 AM, M. Manna wrote: > >> > > Hello, > >> > > > >> > > I opened a very simple KIP and there exists a JIRA for it. > >> > > > >> > > I would be grateful if any comments are available for action. > >> > > > >> > > Regards, > >> > > >> > > > > >
Re: [DISCUSS] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
+including both dev and user mailing lists. Hi, Thanks for the KIP. "* For us, the message keys represent some metadata which we use to either ignore messages (if a loop-back to the sender), or log some information.*" Above statement was mentioned in the KIP about how key value is used. I guess the topic is not configured to be compacted and you do not want to have partitioning based on that key. IMHO, it qualifies more as a header than a key. What do you think about building records with a specific header and consumers to execute the logic whether to process or ignore the messages based on that header value. Thanks, Satish. On Fri, Aug 31, 2018 at 1:32 AM, Satish Duggana wrote: > Hi, > Thanks for the KIP. > > "* For us, the message keys represent some metadata which we use to > either ignore messages (if a loop-back to the sender), or log some > information.*" > > Above statement was mentioned in the KIP about how key value is used. I > guess the topic is not configured to be compacted and you do not want to > have partitioning based on that key. IMHO, it qualifies more as a header > than a key. What do you think about building records with a specific header > and consumers to execute the logic whether to process or ignore the > messages based on that header value. > > Thanks, > Satish. > > > On Fri, Aug 31, 2018 at 12:02 AM, M. Manna wrote: > >> Hi Harsha, >> >> thanks for reading the KIP. >> >> The intent is to use the DefaultPartitioner logic for round-robin >> selection >> of partition regardless of key type. >> >> Implementing Partitioner interface isn’t the issue here, you would have to >> do that anyway if you are implementing your own. But we also want this to >> be part of formal codebase. >> >> Regards, >> >> On Thu, 30 Aug 2018 at 16:58, Harsha wrote: >> >> > Hi, >> > Thanks for the KIP. I am trying to understand the intent of the >> > KIP. Is the use case you specified can't be achieved by implementing >> the >> > Partitioner interface here? >> > https://github.com/apache/kafka/blob/trunk/clients/src/main/ >> java/org/apache/kafka/clients/producer/Partitioner.java#L28 >> > . >> > Use your custom partitioner to be configured in your producer clients. >> > >> > Thanks, >> > Harsha >> > >> > On Thu, Aug 30, 2018, at 1:45 AM, M. Manna wrote: >> > > Hello, >> > > >> > > I opened a very simple KIP and there exists a JIRA for it. >> > > >> > > I would be grateful if any comments are available for action. >> > > >> > > Regards, >> > >> > >
Re: [DISCUSS] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
Hey Bill, Thanks for reading the KIP, much appreciated. The reason we want it to be a separate Partitioner is because: a) We don’t want to specify partition anywhere. b) we want to be able to reuse what’s been done for NULL key in DefaultPartitioner. Using the constructor means we need to assign partition manually in the code. I’m not sure if it I managed to clarify our need. Also, this means no change in any existing code. It’s a new class in Kafka trunk which doesn’t disrupt any exising operation. Thanks, On Thu, 30 Aug 2018 at 18:12, Bill Bejeck wrote: > Hi, > > NOTE: I sent this earlier, but that message just went to the dev list. I'm > including both users and dev now. > > Thanks for the KIP. > > Have you considered using the overloaded ProducerRecord constructor where > you can specify the partition? I mention this as an option as I > encountered the same issue on a previous project and that is how we handled > round-robin distribution with non-null keys. > > Would that suit your needs? > > Thanks, > Bill > > On Thu, Aug 30, 2018 at 11:58 AM Harsha wrote: > > > Hi, > > Thanks for the KIP. I am trying to understand the intent of the > > KIP. Is the use case you specified can't be achieved by implementing the > > Partitioner interface here? > > > https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/producer/Partitioner.java#L28 > > . > > Use your custom partitioner to be configured in your producer clients. > > > > Thanks, > > Harsha > > > > On Thu, Aug 30, 2018, at 1:45 AM, M. Manna wrote: > > > Hello, > > > > > > I opened a very simple KIP and there exists a JIRA for it. > > > > > > I would be grateful if any comments are available for action. > > > > > > Regards, > > >
Re: [DISCUSS] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
Hi, NOTE: I sent this earlier, but that message just went to the dev list. I'm including both users and dev now. Thanks for the KIP. Have you considered using the overloaded ProducerRecord constructor where you can specify the partition? I mention this as an option as I encountered the same issue on a previous project and that is how we handled round-robin distribution with non-null keys. Would that suit your needs? Thanks, Bill On Thu, Aug 30, 2018 at 11:58 AM Harsha wrote: > Hi, > Thanks for the KIP. I am trying to understand the intent of the > KIP. Is the use case you specified can't be achieved by implementing the > Partitioner interface here? > https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/producer/Partitioner.java#L28 > . > Use your custom partitioner to be configured in your producer clients. > > Thanks, > Harsha > > On Thu, Aug 30, 2018, at 1:45 AM, M. Manna wrote: > > Hello, > > > > I opened a very simple KIP and there exists a JIRA for it. > > > > I would be grateful if any comments are available for action. > > > > Regards, >
Re: [DISCUSS] KIP-369: Alternative Partitioner to Support "Always Round-Robin" Selection
Hi, Thanks for the KIP. Have you considered using the overloaded ProducerRecord constructor where you can specify the partition? I mention this as an option as I encountered the same issue on a previous project and that is how we handled round-robin distribution with non-null keys. Would that suit your needs? Thanks, Bill On Thu, Aug 30, 2018 at 6:43 AM M. Manna wrote: > I just added you as a "Watcher". I can see the page via this link - > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89070828 > > 1) visited cwiki.apache.org > 2) Opened "Apache Kafka" from Space Directory > 3) Browsed to Kafka Improvement Proposals (or Design Proposals). > 4) From the side bar menu - > clicked on 363 more child pages. > 5) Found the KIP. > > I used the KIP template described in the "Process" section to create this. > If something is not correct, please advise and I'll amend it. > > Thanks, > > On Thu, 30 Aug 2018 at 11:32, Eno Thereska wrote: > > > Hi there, > > > > I can't see this KIP on the KIP wiki, could you double check? > > > > Thanks > > Eno > > > > On Thu, Aug 30, 2018 at 9:56 AM, M. Manna wrote: > > > > > Hello, > > > > > > I opened a very simple KIP and there exists a JIRA for it. > > > > > > I have already sent it to users' list - but the mail thread doesn't > seem > > to > > > get updated. > > > > > > I would be grateful if any comments are available for action. > > > > > > Regards, > > > > > >
Re: [DISCUSS] KIP-369: Alternative Partitioner to Support "Always Round-Robin" Selection
I just added you as a "Watcher". I can see the page via this link - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89070828 1) visited cwiki.apache.org 2) Opened "Apache Kafka" from Space Directory 3) Browsed to Kafka Improvement Proposals (or Design Proposals). 4) From the side bar menu - > clicked on 363 more child pages. 5) Found the KIP. I used the KIP template described in the "Process" section to create this. If something is not correct, please advise and I'll amend it. Thanks, On Thu, 30 Aug 2018 at 11:32, Eno Thereska wrote: > Hi there, > > I can't see this KIP on the KIP wiki, could you double check? > > Thanks > Eno > > On Thu, Aug 30, 2018 at 9:56 AM, M. Manna wrote: > > > Hello, > > > > I opened a very simple KIP and there exists a JIRA for it. > > > > I have already sent it to users' list - but the mail thread doesn't seem > to > > get updated. > > > > I would be grateful if any comments are available for action. > > > > Regards, > > >
Re: [DISCUSS] KIP-369: Alternative Partitioner to Support "Always Round-Robin" Selection
Hi there, I can't see this KIP on the KIP wiki, could you double check? Thanks Eno On Thu, Aug 30, 2018 at 9:56 AM, M. Manna wrote: > Hello, > > I opened a very simple KIP and there exists a JIRA for it. > > I have already sent it to users' list - but the mail thread doesn't seem to > get updated. > > I would be grateful if any comments are available for action. > > Regards, >
[DISCUSS] KIP-369: Alternative Partitioner to Support "Always Round-Robin" Selection
Hello, I opened a very simple KIP and there exists a JIRA for it. I have already sent it to users' list - but the mail thread doesn't seem to get updated. I would be grateful if any comments are available for action. Regards,
