Hi Artem,
Thank you for all the work on this. I think it'll be quite impactful.
+1 non-binding from me.
Lucas
On Wed, Mar 23, 2022 at 8:27 PM Luke Chen wrote:
> Hi Artem,
>
> Thanks for the KIP and the patience during discussion!
> +1 binding from me.
>
> Luke
>
> On Thu, Mar 24, 2022 at
Congrats Luke :)
On Thu, Feb 10, 2022 at 3:35 AM Jorge Esteban Quilcate Otoya <
quilcate.jo...@gmail.com> wrote:
> Congratulations Luke!
>
> On Thu, 10 Feb 2022 at 09:20, Bruno Cadonna wrote:
>
> > Congrats, Luke! Very well deserved!
> >
> > Best,
> > Bruno
> >
> > On 10.02.22 09:20, Manikumar
Hi Jun,
One difference compared to increasing the default batch size is that users
may actually prefer smaller batches but it makes much less sense to
accumulate many small batches if a batch is already sending.
For example, imagine a user that prefer 16K batches with 5ms linger.
Everything is
[
https://issues.apache.org/jira/browse/KAFKA-12791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Bradstreet resolved KAFKA-12791.
--
Resolution: Fixed
> ConcurrentModificationException in KafkaProducer construc
The other related kernel config that I can recall is
net.ipv4.tcp_max_syn_backlog.
On Mon, Oct 18, 2021 at 4:32 PM Lucas Bradstreet wrote:
> Thank you for the KIP. +1 (non-binding)
>
> For the implementation can we ensure that any kernel parameters that may
> need to also
Thank you for the KIP. +1 (non-binding)
For the implementation can we ensure that any kernel parameters that may
need to also be adjusted are documented in the config documentation
(e.g. net.core.somaxconn)?
On Mon, Oct 18, 2021 at 4:23 PM Haruki Okada wrote:
> Hi Luke.
>
> Thank you for the
Lucas Bradstreet created KAFKA-13342:
Summary: LISR sent for topic queued for deletion in controller
Key: KAFKA-13342
URL: https://issues.apache.org/jira/browse/KAFKA-13342
Project: Kafka
Lucas Bradstreet created KAFKA-13194:
Summary: LogCleaner may clean past highwatermark
Key: KAFKA-13194
URL: https://issues.apache.org/jira/browse/KAFKA-13194
Project: Kafka
Issue Type
Lucas Bradstreet created KAFKA-12896:
Summary: Group rebalance loop caused by repeated group leader
JoinGroups
Key: KAFKA-12896
URL: https://issues.apache.org/jira/browse/KAFKA-12896
Project
Lucas Bradstreet created KAFKA-12791:
Summary: ConcurrentModificationException in KafkaProducer
constructor
Key: KAFKA-12791
URL: https://issues.apache.org/jira/browse/KAFKA-12791
Project: Kafka
Lucas Bradstreet created KAFKA-12736:
Summary: KafkaProducer.flush holds onto completed ProducerBatch(s)
until flush completed
Key: KAFKA-12736
URL: https://issues.apache.org/jira/browse/KAFKA-12736
Congrats Chia-Ping! Thanks for all of your contributions.
On Sat, 13 Mar 2021 at 10:27, Bill Bejeck wrote:
> Congratulations Chia-Ping!
> On Fri, Mar 12, 2021 at 9:03 PM Luke Chen wrote:
>
> > Congratulations Chia-Ping!
> > 恭喜大大！！
> >
> > Luke
> >
> > deng ziming 於 2021年3月13日 週六 上午8:52 寫道：
>
Lucas Bradstreet created KAFKA-12330:
Summary: FetchSessionCache may cause starvation for partitions
when FetchResponse is full
Key: KAFKA-12330
URL: https://issues.apache.org/jira/browse/KAFKA-12330
Lucas Bradstreet created KAFKA-12178:
Summary: Improve guard rails for consumer commit when using EOS
Key: KAFKA-12178
URL: https://issues.apache.org/jira/browse/KAFKA-12178
Project: Kafka
Lucas Bradstreet created KAFKA-12177:
Summary: Retention is not idempotent
Key: KAFKA-12177
URL: https://issues.apache.org/jira/browse/KAFKA-12177
Project: Kafka
Issue Type: Improvement
Lucas Bradstreet created KAFKA-10839:
Summary: Improve consumer group coordinator unavailable message
Key: KAFKA-10839
URL: https://issues.apache.org/jira/browse/KAFKA-10839
Project: Kafka
Hi David,
That is a good point that we should clarify. I think we should not commit
to guaranteeing the names or the format of the particular request and
response schemas themselves, though we should guarantee that they are
parseable as JSON. The pre-existing trace logging did not guarantee this
Grats David!
On Fri, Oct 16, 2020 at 9:25 AM Tom Bentley wrote:
> Congratulations David!
>
> On Fri, Oct 16, 2020 at 5:10 PM Bill Bejeck wrote:
>
> > Congrats David! Well deserved.
> >
> > -Bill
> >
> > On Fri, Oct 16, 2020 at 12:01 PM Gwen Shapira wrote:
> >
> > > The PMC for Apache Kafka
Hi Justine,
+1 (non-binding). Thanks for all your hard work on this KIP!
Lucas
On Wed, Oct 14, 2020 at 8:59 AM Jun Rao wrote:
> Hi, Justine,
>
> Thanks for the updated KIP. +1 from me.
>
> Jun
>
> On Tue, Oct 13, 2020 at 2:38 PM Jun Rao wrote:
>
> > Hi, Justine,
> >
> > Thanks for starting
Thanks for the KIP! Non-binding +1
On Fri, Oct 2, 2020 at 3:30 PM Guozhang Wang wrote:
> Thanks Jose! +1 from me.
>
> On Fri, Oct 2, 2020 at 3:18 PM Jose Garcia Sancio
> wrote:
>
> > Hi all,
> >
> > I would like to start a vote on KIP-630.
> >
> > KIP:
Hi Anastasia,
This looks like a great change that will make debugging cluster behavior
much easier.
+1 non binding.
Lucas
On Wed, Sep 30, 2020 at 11:19 AM Anastasia Vela wrote:
> Hi everyone,
>
> Thanks again for the discussion. I'd like to start the vote for this KIP.
>
>
then why would you need the id name
> mapping file?
>
> Ismael
>
> On Thu, Sep 24, 2020 at 4:24 PM Lucas Bradstreet
> wrote:
>
> > > 2. Part of the usage of the file is to have persistent storage of the
> > topic
> > ID and use it to compare with the ID
ope when the KIP was written.
Yeah, I was hoping to get a better understanding of why it was taken out of
scope. Perhaps Lucas Bradstreet might have more insight about the decision.
Basically my point is that we have to create additional infrastructure here
to support the name/id mapping, so I wan
gt; That's an interesting thought as well. Are you trying to avoid the need to
> specify it through the command line? The tool could also query the value
> with DescribeConfigs I suppose.
>
> Thanks,
> Jason
>
> On Thu, Aug 27, 2020 at 10:48 AM Lucas Bradstreet
> w
Hi Jason,
This looks like a very useful tool, thanks for writing it up.
Given that it's possible for replica producer states to diverge from each
other, it would be very useful if DescribeProducers(Request,Response) and
tooling is able to query all partition replicas for their producers. One
way
Lucas Bradstreet created KAFKA-10432:
Summary: LeaderEpochCache is incorrectly recovered on segment
recovery for epoch 0
Key: KAFKA-10432
URL: https://issues.apache.org/jira/browse/KAFKA-10432
Lucas Bradstreet created KAFKA-10399:
Summary: Producer and consumer clients could log IP addresses for
brokers to ease debugging
Key: KAFKA-10399
URL: https://issues.apache.org/jira/browse/KAFKA-10399
Lucas Bradstreet created KAFKA-10390:
Summary: kafka-server-stop lookup is not specific enough and may
kill other processes
Key: KAFKA-10390
URL: https://issues.apache.org/jira/browse/KAFKA-10390
Lucas Bradstreet created KAFKA-9946:
---
Summary: KAFKA-9539/StopReplicaRequest deletePartition changes may
cause premature topic deletion handling in controller
Key: KAFKA-9946
URL: https://issues.apache.org/jira
Lucas Bradstreet created KAFKA-9864:
---
Summary: Avoid expensive QuotaViolationException usage
Key: KAFKA-9864
URL: https://issues.apache.org/jira/browse/KAFKA-9864
Project: Kafka
Issue Type
Lucas Bradstreet created KAFKA-9820:
---
Summary: validateMessagesAndAssignOffsetsCompressed allocates
batch iterator which is not used
Key: KAFKA-9820
URL: https://issues.apache.org/jira/browse/KAFKA-9820
[
https://issues.apache.org/jira/browse/KAFKA-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Bradstreet resolved KAFKA-8963.
-
Fix Version/s: 2.5.0
Resolution: Fixed
> Benchmark and optimize incremental fe
Lucas Bradstreet created KAFKA-9577:
---
Summary: Client encountering SASL_HANDSHAKE protocol version
errors on 2.5 / trunk
Key: KAFKA-9577
URL: https://issues.apache.org/jira/browse/KAFKA-9577
[
https://issues.apache.org/jira/browse/KAFKA-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Bradstreet resolved KAFKA-9137.
-
Resolution: Fixed
Closed by [https://github.com/apache/kafka/pull/7640]
> Maintena
Hi Harsha,
Is the problem you'd like addressed the following?
Assume 3 replicas, L and F1 and F2.
1. F1 and F2 are alive and sending fetch requests to L.
2. L starts encountering disk issues, any requests being processed by
the request handler threads become blocked.
3. L's zookeeper connection
Lucas Bradstreet created KAFKA-9513:
---
Summary: Failed GroupMetadataManager loadGroupAndOffsets will
consider groups as loaded
Key: KAFKA-9513
URL: https://issues.apache.org/jira/browse/KAFKA-9513
Lucas Bradstreet created KAFKA-9401:
---
Summary: High lock contention for
kafka.server.FetchManager.newContext
Key: KAFKA-9401
URL: https://issues.apache.org/jira/browse/KAFKA-9401
Project: Kafka
+1 (non binding)
On Sat, 11 Jan 2020 at 02:32, M. Manna wrote:
> Hey Colin,
>
> +1 - Really useful for folks managing a cluster by themselves.
>
> M. MAnna
>
> On Fri, 10 Jan 2020 at 22:35, Jose Garcia Sancio
> wrote:
>
> > +1, LGTM.
> >
> > On Fri, Jan 10, 2020 at 2:19 PM Gwen Shapira wrote:
Hi Colin,
This is a great idea, as it is very useful to have these metrics in
addition to the usual Kafka metrics given the impact of hitting disk
outside of page cache. Describing it as a gauge did initially strike me as
oldd, but given the way this is works it makes sense to me.
/proc/[pid]/io
Lucas Bradstreet created KAFKA-9393:
---
Summary: DeleteRecords triggers extreme lock contention for large
partition directories
Key: KAFKA-9393
URL: https://issues.apache.org/jira/browse/KAFKA-9393
+1 (non-binding)
On Thu, Jan 2, 2020 at 11:15 AM Brian Byrne wrote:
> Hello all,
>
> After further discussion and improvements, I'd like to reinstate the voting
> process.
>
> The updated KIP: https://cwiki.apache.org/confluence/display/KAFKA/KIP-526
>
Lucas Bradstreet created KAFKA-9359:
---
Summary: Controller does not handle requests while broker is being
shutdown
Key: KAFKA-9359
URL: https://issues.apache.org/jira/browse/KAFKA-9359
Project
Lucas Bradstreet created KAFKA-9358:
---
Summary: Explicitly resign controller leadership and broker znode
Key: KAFKA-9358
URL: https://issues.apache.org/jira/browse/KAFKA-9358
Project: Kafka
Lucas Bradstreet created KAFKA-9338:
---
Summary: Incremental fetch sessions do not maintain or use leader
epoch for fencing purposes
Key: KAFKA-9338
URL: https://issues.apache.org/jira/browse/KAFKA-9338
Lucas Bradstreet created KAFKA-9312:
---
Summary: KafkaProducer flush behavior does not guarantee send
completion under record batch splitting
Key: KAFKA-9312
URL: https://issues.apache.org/jira/browse/KAFKA-9312
Lucas Bradstreet created KAFKA-9200:
---
Summary: ListOffsetRequest missing error response for v5
Key: KAFKA-9200
URL: https://issues.apache.org/jira/browse/KAFKA-9200
Project: Kafka
Issue
Lucas Bradstreet created KAFKA-9193:
---
Summary: org.apache.kafka.common.utils.Timer should use monotonic
clock
Key: KAFKA-9193
URL: https://issues.apache.org/jira/browse/KAFKA-9193
Project: Kafka
This would be great. Maintaining Scala 2.11 support is reasonably painful.
Dropping support in 2.5 sounds good to me.
On Thu, 7 Nov 2019 at 17:35, Ismael Juma wrote:
> Hi all,
>
> I think it's time to simplify our development environment by dropping
> support for Scala 2.11. Please take a look
Lucas Bradstreet created KAFKA-9137:
---
Summary: Maintenance of FetchSession cache causing
FETCH_SESSION_ID_NOT_FOUND in live sessions
Key: KAFKA-9137
URL: https://issues.apache.org/jira/browse/KAFKA-9137
Lucas Bradstreet created KAFKA-9048:
---
Summary: Improve partition scalability in replica fetcher
Key: KAFKA-9048
URL: https://issues.apache.org/jira/browse/KAFKA-9048
Project: Kafka
Issue
Hi Brian,
This looks great, and should help reduce blocking and high metadata request
volumes when the producer is sending to large numbers of topics, especially
at low volumes. I think the approach to make metadata fetching asynchronous
and batch metadata requests together will help
Lucas Bradstreet created KAFKA-8963:
---
Summary: Benchmark and optimize incremental fetch session handler
Key: KAFKA-8963
URL: https://issues.apache.org/jira/browse/KAFKA-8963
Project: Kafka
[
https://issues.apache.org/jira/browse/KAFKA-8899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Bradstreet resolved KAFKA-8899.
-
Resolution: Duplicate
Duplicate of https://issues.apache.org/jira/browse/KAFKA-8841
Lucas Bradstreet created KAFKA-8899:
---
Summary: Optimize Partition.maybeIncrementLeaderHW
Key: KAFKA-8899
URL: https://issues.apache.org/jira/browse/KAFKA-8899
Project: Kafka
Issue Type
Hi all,
I would like to kick off discussion of KIP-516, an implementation of topic
IDs for Kafka. Topic IDs aim to solve topic uniqueness problems in Kafka,
where referring to a topic by name alone is insufficient. Such cases
include when a topic has been deleted and recreated with the same name.
Lucas Bradstreet created KAFKA-8872:
---
Summary: Improvements to controller "deleting" state / topic
Identifiers
Key: KAFKA-8872
URL: https://issues.apache.org/jira/browse/KAFKA-8872
Proj
Hi,
Could I please be given permission to add a KIP to
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals?
My username is lucasbradstreet.
Thanks
Lucas Bradstreet created KAFKA-8499:
---
Summary: Ducker missing java commands in path for ducker user on
openjdk docker images
Key: KAFKA-8499
URL: https://issues.apache.org/jira/browse/KAFKA-8499
Lucas Bradstreet created KAFKA-8125:
---
Summary: Check for topic existence in CreateTopicsRequest prior to
creating replica assignment
Key: KAFKA-8125
URL: https://issues.apache.org/jira/browse/KAFKA-8125
Lucas Bradstreet created KAFKA-7410:
---
Summary: Rack aware partitions assignment create unbalanced broker
assignments on unbalanced racks
Key: KAFKA-7410
URL: https://issues.apache.org/jira/browse/KAFKA-7410
60 matches
Mail list logo
