Oleg, I believe 0.9 producer gave you the control "max.block.ms" now
On Wed, Mar 30, 2016 at 5:31 AM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:
> I'll buy both 'back pressure' and 'block' argument, but what does it have
> to do with the Future? Isn't that the main point of the Futur
I'll buy both 'back pressure' and 'block' argument, but what does it have to do
with the Future? Isn't that the main point of the Future - a reference to an
invocation that may or may not occur some time in the future? Isn't that the
purpose of the Future.get(..) to give user a choice and chanc
Somewhat of an aside, but you might note that the kafka producer is
intended to block during send() as backpressure on memory allocation.
This is admittedly different than blocking on metadata, but it is worth
considering that the premise that send() should *never* block because
it returns a Future
I also agree that returning a Future should never block. I have brought
this up when 0.8.2 was first released for new Java producer.
As Oleg said, KafkaProducer can also block if metadata is not fetched. This
is probably more often than offline broker, because metadata is loaded
lazily when there
I agree and considering that send(..) method returns Future one would argue it
must never block, otherwise what’s the point of returning Future if you remove
user’s ability to control how long are they willing to wait and what to do when
certain types of exception arise. Nevertheless it does and
Hello,
as documentation says, the KafkaProducer.send() method is asynchronous and it
just returns immediately.I found out that it's not so true when the Kafka
server it's trying to connect isn't online.Of course it happens only on the
first send() method invocation. It means that if the Kafka se
