I totally agree with Oleg.
As documentation says the producers send data in an asynchronous way and it is
enforced by the send method signature with a Future returned.
It can't block indefinitely without returning to the caller.
I'm mean, you can decide that the code inside the send method blocks
indefinitely but in an "asynchronous way", it should first return a Future to
the caller that can handle it.
Paolo.
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience
> Subject: KafkaProducer block on send
> From: ozhurakou...@hortonworks.com
> To: users@kafka.apache.org
> Date: Thu, 7 Apr 2016 13:04:49 +0000
>
> I know it’s been discussed before, but that conversation never really
> concluded with any reasonable explanation, so I am bringing it up again as I
> believe this is a bug that would need to be fixed in some future release.
> Can someone please explain the rational for the following code in
> KafkaProducer:
>
> @Override
> public Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback
> callback) {
> try {
> // first make sure the metadata for the topic is available
> long waitedOnMetadataMs = waitOnMetadata(record.topic(),
> this.maxBlockTimeMs);
> . . .
> }
>
> By definition the method that returns Future implies that caller decides how
> long to wait for the completion via Future.get(TIMETOWAIT). In this case
> there is an explicit blocking call (waitOnMetadata), that can hang infinitely
> (regardless of the reasons) which essentially results in user’s code deadlock
> since the Future may never be returned in the first place.
>
> Thoughts?
>
> Oleg
>
