[ 
https://issues.apache.org/jira/browse/KAFKA-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711690#comment-13711690
 ] 

Guozhang Wang commented on KAFKA-925:
-------------------------------------

Hi Jay,

In the DefaultEventHandler, only the key is serialized and sent. The partition 
key is used to determine the partition and then dropped. So the consumers would 
not be able to read this partition key. Will this be a problem for, for example 
MirrorMaker?

Guozhang
                
> Add optional partition key override in producer
> -----------------------------------------------
>
>                 Key: KAFKA-925
>                 URL: https://issues.apache.org/jira/browse/KAFKA-925
>             Project: Kafka
>          Issue Type: New Feature
>          Components: producer 
>    Affects Versions: 0.8.1
>            Reporter: Jay Kreps
>            Assignee: Jay Kreps
>         Attachments: KAFKA-925-v1.patch, KAFKA-925-v2.patch
>
>
> We have a key that is used for partitioning in the producer and stored with 
> the message. Actually these uses, though often the same, could be different. 
> The two meanings are effectively:
> 1. Assignment to a partition
> 2. Deduplication within a partition
> In cases where we want to allow the client to take advantage of both of these 
> and they aren't the same it would be nice to allow them to be specified 
> separately.
> To implement this I added an optional partition key to KeyedMessage. When 
> specified this key is used for partitioning rather than the message key. This 
> key is of type Any and the parametric typing is removed from the partitioner 
> to allow it to work with either key.
> An alternative would be to allow the partition id to specified in the 
> KeyedMessage. This would be slightly more convenient in the case where there 
> is no partition key but instead you know a priori the partition number--this 
> case must be handled by giving the partition id as the partition key and 
> using an identity partitioner which is slightly more roundabout. However this 
> is inconsistent with the normal partitioning which requires a key in the case 
> where the partition is determined by a key--in that case you would be 
> manually calling your partitioner in user code. It seems best to me to either 
> use a key or always a partition and since we currently take a key I stuck 
> with that.

--
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