Build failed in Jenkins: kafka-2.4-jdk8 #67

See Changes: [rajinisivaram] KAFKA-9171: Handle ReplicaNotAvailableException during DelayedFetch [rajinisivaram] HOTFIX: Fix compilation error in DelayedFetchTest (#7680)

Jenkins build is back to normal : kafka-trunk-jdk8 #4034

See

Re: [VOTE] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

This is not a bug fix, in my opinion. The existing behavior may be confusing, but it was documented, so I assume it was intended. Ismael On Mon, Nov 11, 2019, 2:47 PM Guozhang Wang wrote: > Thanks for the update Brian, I think I agree with Colin that we should > clarify on whether / how the

Jenkins build is back to normal : kafka-trunk-jdk11 #949

See

RE: [DISCUSS] KIP-280: Enhanced log compaction

Hi Jun, Thanks for the response and please find below the response! #50 - got it... #51 - not sure how the last record will be deleted bcoz of this new compact strategy. The reason I am asking is, the compaction is based out of offsetmap and the new strategy logic is purely within the

Jenkins build is back to normal : kafka-2.4-jdk8 #66

See

Re: Why standby tasks read from the StandbyTasks::checkpointedOffsets in assignStandbyPartitions()

Ok, created: https://github.com/apache/kafka/pull/7681 I'm on the fence about whether we should file this as a 2.4.0 blocker. It _sounds_ like this would have a pretty big impact on performance. I'm not convinced about any correctness problems, though, since the changelogs are only configured

Re: [VOTE] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

Thanks for the update Brian, I think I agree with Colin that we should clarify on whether / how the blocking behavior due to metadata fetch would be affected or not. About whether this needs to be voted as a KIP: to me the behavior change is really a bug fix rather than a public contract change,

Re: Why standby tasks read from the StandbyTasks::checkpointedOffsets in assignStandbyPartitions()

Hi all, I've just been looking over the code and Guozhang's reply... I think that the reply is reasonable, but it seems like the code may not be precisely implementing this logic. As an entry point, in `StreamThread#runOnce`: If the state is `PARTITIONS_ASSIGNED`, we'll call

Re: [DISCUSS] KIP-535: Allow state stores to serve stale reads during rebalance

Regarding 1.2: StreamsMetadata is 1-1 mapped to the streams instances, so 1) allMetadata would still return the same number of StreamsMetadata in collection, just that within the StreamsMetadata now you have new APIs to access standby partitions / stores. So I think it would not be a breaking

Re: [DISCUSS] KIP-409: Allow creating under-replicated topics and partitions

Hi Mickael, Thanks for the revisions. It looks good overall. best, Colin On Mon, Nov 11, 2019, at 03:45, Mickael Maison wrote: > Hi all, > > If there's no more feedback, I'll open a vote in the next few days. > > Thanks > > On Wed, Nov 6, 2019 at 11:35 AM Mickael Maison > wrote: > > > >

[jira] [Resolved] (KAFKA-9171) DelayedFetch completion may throw exception, causing successful produce to be failed

[ https://issues.apache.org/jira/browse/KAFKA-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram resolved KAFKA-9171. --- Reviewer: Ismael Juma Resolution: Fixed > DelayedFetch completion may throw exception,

Re: [VOTE] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

Hi Brian, Thanks for the KIP. Starting the metadata fetch before we need the result is definitely a great idea. This way, the metadata fetch can be done in parallel with all the other stuff e producer is doing, rather than forcing the producer to periodically come to a halt periodically

Re: [DISCUSS] KIP-221: Repartition Topic Hints in Streams

Ah, thanks for the clarification. I missed your point. I like the framework you've presented. It does seem simpler to assume that they either care about the partition count and want to repartition to realize it, or they don't care about the number. Returning to this discussion, it does seem

Re: [DISCUSS] Apache Kafka 2.4.0 release

Hi all, I am trying to get stable system test runs on 2.4 branch. While analyzing the ReassignPartitionsTest failure, Rajini identified a issue, which can cause a successful produce to be failed. Thanks to Rajini for identifying the issue. https://issues.apache.org/jira/browse/KAFKA-9171

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

See Changes: [github] MINOR: Change topic-exists log for CreateTopics from INFO to DEBUG -- [...truncated 5.56 MB...] org.apache.kafka.streams.TopologyTestDriverTest >

Re: [VOTE] KIP-544: Make metrics exposed via JMX configurable

+1 (non-binding). Thanks Xavier On Sat, Nov 9, 2019 at 9:54 AM Manikumar wrote: > +1 (binding). Thanks for the KIP. > > > On Sat, Nov 9, 2019 at 3:11 PM Alexandre Dupriez < > alexandre.dupr...@gmail.com> wrote: > > > +1 (non-binding) > > > > Le ven. 8 nov. 2019 à 20:21, Bill Bejeck a écrit :

Build failed in Jenkins: kafka-2.4-jdk8 #65

See Changes: -- [...truncated 5.45 MB...] org.apache.kafka.streams.test.OutputVerifierTest > shouldFailIfTimestampIsDifferentForCompareValueTimestamp PASSED

[jira] [Created] (KAFKA-9171) DelayedFetch completion may throw exception, causing successful produce to be failed

Rajini Sivaram created KAFKA-9171: - Summary: DelayedFetch completion may throw exception, causing successful produce to be failed Key: KAFKA-9171 URL: https://issues.apache.org/jira/browse/KAFKA-9171

Build failed in Jenkins: kafka-trunk-jdk11 #948

See Changes: [github] MINOR: Change topic-exists log for CreateTopics from INFO to DEBUG -- [...truncated 2.75 MB...] org.apache.kafka.streams.MockTimeTest >

Re: [DISCUSS] KIP-409: Allow creating under-replicated topics and partitions

Hi all, If there's no more feedback, I'll open a vote in the next few days. Thanks On Wed, Nov 6, 2019 at 11:35 AM Mickael Maison wrote: > > Hi, > > Thanks Colin for the feedback. Edo and I have updated the KIP > accordingly. Can you take another look? > > > On Tue, Oct 22, 2019 at 12:20 AM

Re: [DISCUSS] KIP-518: Allow listing consumer groups per state

Hi all, If there's no more feedback, I'll open a vote in the next few days. Thanks On Fri, Nov 1, 2019 at 4:27 PM Mickael Maison wrote: > > Hi Tom, > > Thanks for taking a look at the KIP! > You are right, even if we serialize the field as a String, we should > use ConsumerGroupState in the

Re: [ANNOUNCE] New committer: Mickael Maison

Thanks everyone! On Mon, Nov 11, 2019 at 4:35 AM Kamal Chandraprakash wrote: > > Congrats Mickael! > > On Sat, Nov 9, 2019 at 4:47 AM Sean Glover > wrote: > > > Congratulations Mickael :) > > > > On Fri, Nov 8, 2019 at 12:28 PM Ankit Kumar > > wrote: > > > > > Congratulations Mickael!! > > > >

[jira] [Created] (KAFKA-9170) KafkaStreams constructor fails to read configuration from Properties object created with default values

Oleg Muravskiy created KAFKA-9170: - Summary: KafkaStreams constructor fails to read configuration from Properties object created with default values Key: KAFKA-9170 URL: