[
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