Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

at 2:21 PM Colin McCabe wrote: > On Tue, Jun 1, 2021, at 12:22, Nakamura wrote: > > I think we're talking past each other a bit. I know about non-blocking > > I/O. The problem I'm facing is how to preserve the existing semantics > > without blocking. Right now calle

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

ot in the default case. > > I actually don't have any objections to this approach so long as it's > opt-in. It sounds like you are suggesting to fix the bug for everyone, but > I don't think we can do that without subtly breaking things. > > Ryanne > > On Tue, Jun

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

ou mind helping me figure out what it is? Best, Moses On Sun, May 30, 2021 at 5:35 PM Colin McCabe wrote: > On Tue, May 25, 2021, at 11:26, Nakamura wrote: > > Hey Colin, > > > > For the metadata case, what would fixing the bug look like? I agree that > > we should fi

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

is properly, but it is > a possibility. I suspect that most of them wouldn't use this, but we could > offer it as a possibility for async purists (which might include certain > frameworks). The big problem the users would have to solve is what to do > with the record that the

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

20, 2021 at 7:26 AM Matthew de Detrich wrote: > @ > > Nakamura > On Wed, May 19, 2021 at 7:35 PM Nakamura wrote: > > > @Ryanne: > > In my mind's eye I slightly prefer the throwing the "cannot enqueue" > > exception to satisfying the future immediately

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

r a spot in the queue > > definitely defeats the purpose (tho perhaps ameliorates the problem > some). > > > > Throwing an exception to the caller directly (not via the future) is > > another option with precedent in Kafka clients, tho it doesn't seem as > >

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

gt; Ryanne > > On Tue, May 18, 2021, 10:39 AM Nakamura wrote: > > > Hi Alexandre, > > > > Thanks for bringing this up, I think I could use some feedback in this > > area. There are two mechanisms here, one for slowing down when we don't > > have

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

want to enqueue messages that would push us over the limit, and would only want to enqueue messages when we're waiting for metadata, and we would want to keep track of the total number of bytes for those messages). What do you think? Best, Moses On Sun, May 16, 2021 at 6:16 AM Alexandre Dupr

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

ad the future would fail. I think that might mean that > a new method signature is required. > > Ryanne > > > On Thu, May 13, 2021, 2:57 PM Nakamura wrote: > > > Hey Ryanne, > > > > I agree we should add an additional constructor (or else an additional > > o

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

> way, which returns right away and uses an internal Executor. As you point > out, the semantics would be identical in either case, and it would be very > easy for clients to switch. > > Ryanne > > On Thu, May 13, 2021, 9:00 AM Nakamura wrote: > > > Hey Folks, > &

[DISCUSS] KIP-739: Block Less on KafkaProducer#send

Hey Folks, I just posted a new proposal in the wiki. I think we have an opportunity to improve the KafkaProducer#send user experience. It would certainly make our lives easier. Please take a look! There are two subprob

Re: please give me permission to create a KIP

Thank you! On Wed, May 12, 2021 at 4:37 PM Matthias J. Sax wrote: > Added you. > > On 5/12/21 9:23 AM, Nakamura wrote: > > Hi Folks, > > I'd like to propose a KIP per Ewen's advice here > > < > https://issues.apache.org/jira/browse/KAFKA-3539?focusedC

please give me permission to create a KIP

Hi Folks, I'd like to propose a KIP per Ewen's advice here . However, I don't have permission to create a KIP yet. Please grant it to me! My username at cwiki.apache.org is moses.nakamura. Thanks! Best, Moses