t;>
>>>> Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
>>>> Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
>>>> Twitter : @ppatierno
>>>> Linkedin : paolopatierno
>>>> Blog : DevExperience
>>>>
>>
gt; > >
> > > Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
> > > Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
> > > Twitter : @ppatierno
> > > Linkedin : paolopatierno
> > > Blog : DevExperience
> > >
> > >
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
> > Twitter : @ppatierno
> > Linkedin : paolopatierno
> > Blog : DevExperience
> >
> >> Subject: Re: KafkaProducer block on send
> >> From: ozhurakou...@hortonworks.com
> >> To: users@kafk
It's sad that after almost one month it's still "unassigned" :-(
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience
> Subject: Re:
soft Azure Advisor
> Twitter : @ppatierno
> Linkedin : paolopatierno
> Blog : DevExperience
>
>> Subject: Re: KafkaProducer block on send
>> From: ozhurakou...@hortonworks.com
>> To: users@kafka.apache.org
>> Date: Wed, 4 May 2016 14:47:25 +
>>
>&g
Linkedin : paolopatierno
Blog : DevExperience
Subject: Re: KafkaProducer block on send
From: ozhurakou...@hortonworks.com<mailto:ozhurakou...@hortonworks.com>
To: users@kafka.apache.org<mailto:users@kafka.apache.org>
Date: Mon, 11 Apr 2016 19:42:17 +
Dana
Thanks for the e
xperience
> From: ppatie...@live.com
> To: users@kafka.apache.org
> Subject: RE: KafkaProducer block on send
> Date: Wed, 4 May 2016 07:24:25 +
>
> Hi Oleg,
>
> can you share the JIRA link here because I totally agree with you.
> For me the send() should be total
(IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience
> Subject: Re: KafkaProducer block on send
> From: ozhurakou...@hortonworks.com
> To: users@kafka.apache.org
> Date: Mon, 11 Ap
Dana
Thanks for the explanation, but it sounds more like a workaround since
everything you describe could be encapsulated within the Future itself. After
all it "represents the result of an asynchronous computation"
executor.submit(new Callable() {
@Override
public RecordMetadata call
The prior discussion explained:
(1) The code you point to blocks for a maximum of max.block.ms, which is
user configurable. It does not block indefinitely with no user control as
you suggest. You are free to configure this to 0 if you like at it will not
block at all. Have you tried this like I su
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
11 matches
Mail list logo
