[
https://issues.apache.org/jira/browse/KAFKA-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539451#comment-14539451
]
Gwen Shapira commented on KAFKA-2176:
-------------------------------------
1. Regarding battle testing, LinkedIn is the biggest MirrorMaker user AFAIK, so
I'll let [~guozhang], your original reviewer reply to that
2. As I said, I'd rather put efforts into improving the new clients and declare
the existing as "deprecated" rather than keep maintaining them.
I know the old producer is still used, but the way features are typically
deprecated is that when someone runs into this issue, we recommend migrating to
the newer code.
Anyway, since you already patched the old one, I'll make [~guozhang] make that
call. Just giving my 2c and letting you know you can test the new producer (the
one we actually put a lot of effort into improving).
> DefaultPartitioner doesn't perform consistent hashing based on
> ---------------------------------------------------------------
>
> Key: KAFKA-2176
> URL: https://issues.apache.org/jira/browse/KAFKA-2176
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.8.1
> Reporter: Igor Maravić
> Labels: easyfix, newbie
> Fix For: 0.8.1
>
> Attachments: KAFKA-2176.patch
>
>
> While deploying MirrorMakers in production, we configured it to use
> kafka.producer.DefaultPartitioner. By doing this and since we had the same
> amount partitions for the topic in local and aggregation cluster, we expect
> that the messages will be partitioned the same way.
> This wasn't the case. Messages were properly partitioned with
> DefaultPartitioner on our local cluster, since the key was of the type String.
> On the MirrorMaker side, the messages were not properly partitioned.
> Problem is that the Array[Byte] doesn't implement hashCode function, since it
> is mutable collection.
> Fix is to calculate the deep hash code if the key is of Array type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
