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
+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-
>
>
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
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
+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
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
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
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
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
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
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,
11 matches
Mail list logo
