Chia-Ping Tsai created KAFKA-6992:
-------------------------------------

             Summary: Configuring the batch.size to zero won't disable the 
batching entirely
                 Key: KAFKA-6992
                 URL: https://issues.apache.org/jira/browse/KAFKA-6992
             Project: Kafka
          Issue Type: Bug
          Components: documentation
            Reporter: Chia-Ping Tsai


In MAGIC_VALUE_V2, the varint is used and the estimated size won't be equal 
with the actual size. So it has chance to accept more records in a single 
produce batch.

Perhaps we should revise the docs of batch.size.
{code:java}
public static final String BATCH_SIZE_CONFIG = "batch.size";
private static final String BATCH_SIZE_DOC = "The producer will attempt to 
batch records together into fewer requests whenever multiple records are being 
sent"
                                             + " to the same partition. This 
helps performance on both the client and the server. This configuration 
controls the "
                                             + "default batch size in bytes. "
                                             + "<p>"
                                             + "No attempt will be made to 
batch records larger than this size. "
                                             + "<p>"
                                             + "Requests sent to brokers will 
contain multiple batches, one for each partition with data available to be 
sent. "
                                             + "<p>"
                                             + "A small batch size will make 
batching less common and may reduce throughput (a batch size of zero will 
disable "
                                             + "batching entirely). A very 
large batch size may use memory a bit more wastefully as we will always 
allocate a "
                                             + "buffer of the specified batch 
size in anticipation of additional records.";{code}
 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to