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

Thomas Graves commented on KAFKA-3236:
--------------------------------------

Thanks for the response.  I saw that the config were deprecated in the code but 
we were hoping to bring them back for this use case.

Currently (Kafka 0.9) if block.on.buffer.full = false it blocks up to 
max.block.ms if either the metadata is unavailable of the buffer is full.
The behavior we want (and is implemented in pr) is for it to throw 
BufferExhaustedException immediately instead of waiting the max.block.ms when 
the buffer is full.  We still use max.block.ms for the metadata unavailable.

Do you think this is a reasonable request or is there a reason not to decouple 
these?

> Honor Producer Configuration "block.on.buffer.full"
> ---------------------------------------------------
>
>                 Key: KAFKA-3236
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3236
>             Project: Kafka
>          Issue Type: Improvement
>          Components: producer 
>    Affects Versions: 0.9.0.0
>            Reporter: Thomas Graves
>            Assignee: Thomas Graves
>
> In Kafka-0.9, "max.block.ms" is used to control how long the following 
> methods will block.
> KafkaProducer.send() when
>    * Buffer is full
>    * Metadata is unavailable
> KafkaProducer.partitionsFor() when
>    * Metadata is unavailable
> However when "block.on.buffer.full" is set to false, "max.block.ms" is in 
> effect whenever a buffer is requested/allocated from the Producer BufferPool. 
> Instead it should throw a BufferExhaustedException without waiting for 
> "max.block.ms"
> This is particulary useful if a producer application does not wish to block 
> at all on KafkaProducer.send() . We avoid waiting on KafkaProducer.send() 
> when metadata is unavailable by invoking send() only if the producer instance 
> has fetched the metadata for the topic in a different thread using the same 
> producer instance. However "max.block.ms" is still required to specify a 
> timeout for bootstrapping the metadata fetch.
> We should resolve this limitation by decoupling "max.block.ms" and 
> "block.on.buffer.full".
>    * "max.block.ms" will be used exclusively for fetching metadata when    
> "block.on.buffer.full" = false (in pure non-blocking mode )
>    * "max.block.ms" will be applicable to both fetching metadata as well as 
> buffer allocation when "block.on.buffer.full = true



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to