Ok, thanks for the information. Looking at the wire format for the
metadata response, I see that the right hand side of the TopicMetadata
production contains a TopicErrorCode, and the right hand side of the
PartitionMetadata production contains a PartitionErrorCode. Are both
of these 16-bit
Yes I believe the TopicErrorCode is also an int16. I will update the
documentation accordingly.
In general, if the protocol specification is not explicit it should be
made explicit. This will help other client driver authors in the future.
If you find any other errors or omissions in the
Dave,
Currently, the broker expects each producer request to specify the exact
partition id (-1 is on longer valid). The mapping from a message to a
partition is done at the producer client. The producer can choose a random
partition (from the existing list of partitions) or deterministically
In the version 0.8 wire format for a produce request, does a value of -1
still indicate use a random partition as it did for 0.7?
Thanks,
Dave
I'm looking at the document entitled A Guide to the Kafka Protocol
located here:
https://cwiki.apache.org/KAFKA/a-guide-to-the-kafka-protocol.html
It shows a produce request as containing a number of message sets, which are
grouped first by topic and second by partition (a 32-bit integer).
Dave,
Colin described the producer behavior of picking the partition for a
message before it is sent to Kafka broker correctly. However, I'm
interested in knowing your use case a little before to see why you would
rather have the broker decide the partition?
Thanks,
Neha
On Tue, May 21, 2013
In my case, there is a load balancer between the producers and the
brokers, so I want the behavior described for the Java client (null key
specifies any partition). If the Key field of each individual message
specifies the partition to send it to, then I don't understand the purpose
of the 32-bit
