[ 
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

Reply via email to