[jira] [Resolved] (KAFKA-7903) Replace OffsetCommit request/response with automated protocol

[ https://issues.apache.org/jira/browse/KAFKA-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boyang Chen resolved KAFKA-7903. Resolution: Fixed > Replace OffsetCommit request/response with automated protocol >

Re: [DISCUSS] KIP-315: Stream Join Sticky Assignor

In light of KIP-429, I think there will be an increased demand for sticky assignors. So, I'd like to restart the conversation about adding the sticky streams assignor, https://cwiki.apache.org/confluence/display/KAFKA/KIP-315%3A+Stream+Join+Sticky+Assignor. It’d be great to get feedback on

Build failed in Jenkins: kafka-trunk-jdk8 #3590

See Changes: [jason] MINOR: Fix Embedded ConfigDef Validator toString issue (#6339) -- [...truncated 2.39 MB...] org.apache.kafka.streams.scala.kstream.MaterializedTest

Re: [VOTE] KIP-411: Make default Kafka Connect worker task client IDs distinct

Looks good to me and a very useful feature. +1 ( non-binding) On Mon, Apr 29, 2019, 4:05 PM Arjun Satish wrote: > Thanks, Paul! This is very useful. > > +1 (non-binding) > > Best, > Arjun > > On Fri, Apr 12, 2019 at 4:13 PM Ryanne Dolan > wrote: > > > +1 (non binding) > > > > Thanks > >

Re: [DISCUSS] KIP-440: Extend Connect Converter to support headers

Thanks Yaroslav, this KIP LGTM now too! To give some context regarding my previous comment: headers in Connect would probably have followed a similar approach if default methods in interfaces could be used at the time. But we could not have assumed java 8 or later yet in the AK version that

Re: Fw: [DISCUSS] KIP-462 : Use local thread id for KStreams

Hi Boyang, Thanks for the KIP. I think it makes sense. Just following up on the documentation part: since we are effectively removing this guard against same client.ids of instances --- and btw, semantically we would not forbid users to set the same client.ids anyways for throttling purposes for

Re: [DISCUSS] KIP-458: Connector Client Config Override Policy

Per the proposal, a connector configuration can define one or more properties that begin with any of the three prefixes: "producer.override.", "consumer.override.", and "admin.override.". The proposal states: Since the users can specify any of these policies, the connectors itself should not rely

Re: [VOTE] KIP-411: Make default Kafka Connect worker task client IDs distinct

Thanks, Paul! This is very useful. +1 (non-binding) Best, Arjun On Fri, Apr 12, 2019 at 4:13 PM Ryanne Dolan wrote: > +1 (non binding) > > Thanks > Ryanne > > On Fri, Apr 12, 2019, 11:11 AM Paul Davidson > wrote: > > > Just a reminder that KIP-411 is open for voting. No votes received yet! >

Re: [DISCUSS] KIP-440: Extend Connect Converter to support headers

Thanks for the update. Yes, IMO this KIP is ready for a vote. On Fri, Apr 26, 2019 at 12:15 AM sapie...@gmail.com wrote: > Hi Randall, Konstantine, > > I've updated the KIP to reflect the details we discussed here. Let me know > if it looks good and we can go to the voting phase. > > Thanks! >

[VOT] KIP-449: Add connector contexts to Connect worker logs (vote thread)

I would like to start the vote for KIP-258: https://cwiki.apache.org/confluence/display/KAFKA/KIP-449%3A+Add+connector+contexts+to+Connect+worker+logs The KIP uses the Mapped Diagnostic Contexts (MDC) feature of SLF4J API to add more context to log messages from within Connect workers and

Re: [DISCUSS] KIP-449: Add connector contexts to Connect worker logs

Thanks, Chris and Jeremy. I've fixed the errors that Chris mentioned. I agree with Jeremy that this KIP is limited to the framework dealing with these contexts as part of its logging mechanism, and they're not really for connectors to use. Connector implementations that don't have additional

Re: Wiki Edit Permission (agavra)

Done On 4/29/19 6:53 PM, Almog Gavra wrote: > Hello Kafka Devs, > > I'm following the instructions on > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals, > which first requires me to request edit access on the wiki. > > My JIRA Id is: *agavra* > > Cheers, > Almog >

Re: [DISCUSS] KIP-462 : Use local thread id for KStreams

Could we get more discussions on this thread? Boyang From: Boyang Chen Sent: Friday, April 26, 2019 10:51 PM To: dev@kafka.apache.org Subject: Re: [DISCUSS] KIP-462 : Use local thread id for KStreams Thanks for the explanation Matthias! Will enhance the KIP

Wiki Edit Permission (agavra)

Hello Kafka Devs, I'm following the instructions on https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals, which first requires me to request edit access on the wiki. My JIRA Id is: *agavra* Cheers, Almog

Re: [DISCUSS] KIP-454: Expansion of the ConnectClusterState interface

Hi Chris, Thanks for considering my suggestion regarding default implementations for the new methods. However, given that these implementations don't seem to have sane defaults and throw UnsupportedOperationException, I think we'll be better without defaults. Seems that a compile time error is

[jira] [Created] (KAFKA-8306) Ensure consistency of checkpointed log start offset and current log end offset

Jason Gustafson created KAFKA-8306: -- Summary: Ensure consistency of checkpointed log start offset and current log end offset Key: KAFKA-8306 URL: https://issues.apache.org/jira/browse/KAFKA-8306

[jira] [Created] (KAFKA-8305) AdminClient should support creating topics with `default.replication.factor`

Almog Gavra created KAFKA-8305: -- Summary: AdminClient should support creating topics with `default.replication.factor` Key: KAFKA-8305 URL: https://issues.apache.org/jira/browse/KAFKA-8305 Project:

[jira] [Created] (KAFKA-8304) Connect susceptible to deadlock while registering REST extensions

Chris Egerton created KAFKA-8304: Summary: Connect susceptible to deadlock while registering REST extensions Key: KAFKA-8304 URL: https://issues.apache.org/jira/browse/KAFKA-8304 Project: Kafka

Re: [DISCUSS] KIP-448: Add State Stores Unit Test Support to Kafka Streams Test Utils

Hi, Sorry for the late reply, I have read through all your valuable comments. The KIP still needs work at this point. I think at this point, one question comes up is that, how should we implement the mock stores - as Sophie suggested, should we open to all Store backend and just wrap around the

Re: [VOTE] KIP-434: Dead replica fetcher and log cleaner metrics

Hi Jason, I too agree this is more of a problem in older versions and therefore we could backport it. Were you thinking of any specific versions? I guess the 2.x and 1.x versions are definitely targets here but I was thinking that we might not want to further. Viktor On Mon, Apr 29, 2019 at

[jira] [Resolved] (KAFKA-7779) Avoid unnecessary loop iteration in leastLoadedNode

[ https://issues.apache.org/jira/browse/KAFKA-7779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson resolved KAFKA-7779. Resolution: Fixed > Avoid unnecessary loop iteration in leastLoadedNode >

Re: [DISCUSS] KIP-435: Incremental Partition Reassignment

Hi Folks, I've updated the KIP with the batching which would work on both replica and partition level. To explain it briefly: for instance if the replica level is set to 2 and partition level is set to 3, then 2x3=6 replica reassignment would be in progress at the same time. In case of

[jira] [Created] (KAFKA-8303) Flaky Test SaslSslAdminClientIntegrationTest#testLogStartOffsetCheckpoint

Matthias J. Sax created KAFKA-8303: -- Summary: Flaky Test SaslSslAdminClientIntegrationTest#testLogStartOffsetCheckpoint Key: KAFKA-8303 URL: https://issues.apache.org/jira/browse/KAFKA-8303 Project: