[ https://issues.apache.org/jira/browse/KAFKA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13710571#comment-13710571 ]
Joel Koshy commented on KAFKA-957: ---------------------------------- Thanks for incorporating 5 and 6. Couple additional comments: - For the two match statements you have it is probably sufficient and clearer to just use if (key == null) .... and if (props.contains(..)) - I'm not so sure if the trace is required but it could be useful. Would prefer the following format: "Sending message with key <key>" - no need to show the payload. Also, may want to use java.util.Arrays.toString on the byte array. - Per Jay's offline comments, hashCode in general is a bit unsafe to "rely". For e.g., it could be a non-uniform distribution or the underlying function could change. That said, your usage is safe. Still, it should be straightforward to do a custom hash function that we can rely on for consistency. > MirrorMaker needs to preserve the key in the source cluster > ----------------------------------------------------------- > > Key: KAFKA-957 > URL: https://issues.apache.org/jira/browse/KAFKA-957 > Project: Kafka > Issue Type: Bug > Components: core > Affects Versions: 0.8 > Reporter: Jun Rao > Assignee: Guozhang Wang > Attachments: KAFKA-957.v1.patch, KAFKA-957.v2.patch, > KAFKA-957.v2.patch > > > Currently, MirrorMaker only propagates the message to the target cluster, but > not the associated key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira