Hi all,
Thanks for participating in the discussion and voting! KIP-974 has been
accepted with the following +1 votes:
- Justine Olshan (binding)
- Ismael Juma (binding)
- Manikumar (binding)
- Federico Valeri (non-binding)
Regards,
Krishna
>
>
> I see way too many food-guns and complications that can be introduced.
What is a "food-gun"?? I'm picturing like a spud rifle/potato gun but I
don't think that's what you meant hahaha
I don't feel super strongly one way or another, but I have a few questions
& corrections about some of
Hi Divij,
Thanks for raising this.
The valid minimum value 1 for `segment.ms` is completely unreasonable.
Similarly for `segment.bytes`, `metadata.log.segment.ms`,
`metadata.log.segment.bytes`.
In addition to that, there are also some config default values we'd like to
propose to change in v4.0.
hey guys,
Regarding to num.recovery.threads.per.data.dir: I agree, in our company we
use the number of vCPUs to do so as this is not competing with ready
cluster traffic.
On Wed, 13 Mar 2024 at 09:29, Luke Chen wrote:
> Hi Divij,
>
> Thanks for raising this.
> The valid minimum value 1 for
Divij Vaidya created KAFKA-16368:
Summary: Change constraints and default values for various
configurations
Key: KAFKA-16368
URL: https://issues.apache.org/jira/browse/KAFKA-16368
Project: Kafka
Thanks for the discussion folks. I have started a KIP
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1030%3A+Change+constraints+and+default+values+for+various+configurations
to keep track of the changes that we are discussion. Please consider this
as a collaborative work-in-progress KIP and
Hi all,
I just wanted to bump up this thread.
The KIP introduces a really small change and PR is already ready and only
waiting for this KIP to get approved to be merged.
Thanks,
On Wed, Mar 6, 2024 at 12:26 PM Nelson B. wrote:
> Hi all,
>
> I would like to start a discussion on KIP-1025,
I think it's a great idea to raise a KIP to look at adjusting defaults and
minimum/maximum config values for version 4.0.
As pointed out, the minimum values for segment.ms and segment.bytes don't
make sense and would probably bring down a cluster pretty quickly if set
that low, so version 4.0 is
I had a look at the discussion thread and the KIP looks exciting.
+1 non-binding
Best
Omnia
On 1 Dec 2023, at 19:06, Artem Livshits
wrote:
Hello,
This is a voting thread for
https://cwiki.apache.org/confluence/display/KAFKA/KIP-939%3A+Support+Participation+in+2PC
.
The KIP proposes extending
+ users@kafka
Hi users of Apache Kafka
With the upcoming 4.0 release, we have an opportunity to improve the
constraints and default values for various Kafka configurations.
We are soliciting your feedback and suggestions on configurations where the
default values and/or constraints should be
Hi all,
I just wanted to bump up this thread.
The KIP introduces a really small change and it would not take much of the
time reviewing it. This change would enable kafka users to use tiered
storage features seamlessly for the topics migrated from < 2.8 version
which currently failed with
Thanks Manikumar!
+1 from me
Justine
On Wed, Mar 13, 2024 at 8:52 AM Manikumar wrote:
> Hi,
>
> I'd like to volunteer to be the release manager for a bug fix release of
> the 3.6 line.
> If there are no objections, I'll send out the release plan soon.
>
> Thanks,
> Manikumar
>
Edoardo Comar created KAFKA-16369:
-
Summary: Broker may not shut down when SocketServer fails to bind
as Address already in use
Key: KAFKA-16369
URL: https://issues.apache.org/jira/browse/KAFKA-16369
[
https://issues.apache.org/jira/browse/KAFKA-16171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Arthur resolved KAFKA-16171.
--
Resolution: Fixed
> Controller failover during ZK migration can prevent metadata updates to
+1
Thank you for volunteering.
--
Divij Vaidya
On Wed, Mar 13, 2024 at 4:58 PM Justine Olshan
wrote:
> Thanks Manikumar!
> +1 from me
>
> Justine
>
> On Wed, Mar 13, 2024 at 8:52 AM Manikumar
> wrote:
>
> > Hi,
> >
> > I'd like to volunteer to be the release manager for a bug fix release
+1 thanks for volunteering!
Best
---
Josep Prat
Open Source Engineering Director, aivenjosep.p...@aiven.io |
+491715557497 | aiven.io
Aiven Deutschland GmbH
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
Amtsgericht Charlottenburg, HRB 209739 B
On Wed, Mar
Yes, about the "drop records" case. It's a very common scenario to have
a repartition step before a windowed aggregation or a join with
grace-period.
About "add feature vs guard users": it's always a tricky question and
tradeoff. For this particular KIP, I personally think we should opt to
Hi Arpit,
Thanks for the KIP!
I am not familiar with the necessity of producer snapshots, but your
explanation sounds like this should be made optional.
Can you expand the KIP to include the changes that need to be made to
the constructor and getter, and explain more about backwards
If the custom store is a key-value store, yes, we could do this. But the
interface does not enforce a key-value store, it's just a most generic
`StateStore` that we pass in, and thus it could be something totally
unknown to us, and we cannot apply a cast...
The underlying idea is really about
Hi,
I'd like to volunteer to be the release manager for a bug fix release of
the 3.6 line.
If there are no objections, I'll send out the release plan soon.
Thanks,
Manikumar
Hey folks -- let me summarize my understanding
Artem requested we change the name of transaction version (tv) to
transaction protocol version (tpv). If I do that, I will also probably
change to group coordinator protocol version (gcpv).
Folks were concerned about upgrades/downgrades with
+1, Thanks Mani for volunteering.
On Thu, 14 Mar 2024 at 06:01, Luke Chen wrote:
>
> +1, Thanks Manikumar!
>
> On Thu, Mar 14, 2024 at 3:40 AM Bruno Cadonna wrote:
>
> > Thanks Manikumar!
> >
> > +1
> >
> > Best,
> > Bruno
> >
> > On 3/13/24 5:56 PM, Josep Prat wrote:
> > > +1 thanks for
By "don't add them" do you just mean we would not have any actual
variables defined anywhere for these configs (eg WINDOW_SIZE_MS)
and simply document -- somewhere -- that one can use the string
"window.size.ms" when configuring a command-line client with a
windowed serde? Or something else? I
>
> Well, the KIP mentions the ability to either re-try the record (eg,
> after applying some external fix that would allow Kafka Streams to now
> deserialize the record now) or to skip it by advancing the offset.
That's fair -- you're definitely right that what's described in the KIP
document
About your last two points: I completely agree that we should try to
make this independent of RocksDB, and should probably adopt a
general philosophy of being store-implementation agnostic unless
there is good reason to focus on a particular store type: eg if it was
only possible to implement for
One use case I see for setting the `segment.bytes` to 1 is to delete all
the records from the topic.
We can mention about it in the doc to use the `kafka-delete-records` API
instead.
On Wed, Mar 13, 2024 at 6:59 PM Divij Vaidya
wrote:
> + users@kafka
>
> Hi users of Apache Kafka
>
> With the
Hi,
We have accumulated a number of personal branches in the github
repository: https://github.com/apache/kafka/branches/all
All these branches have been created by committers for various
reasons, bugfix, tests.
I wonder if we should avoid creating branches in the apache repository
(always use
On Wed, Mar 13, 2024 at 11:02 AM Mickael Maison
wrote:
> What do you think?
I agree. I wouldn't be surprised if these branches (not trunk or
release branches) were created by mistake by the committer.
Thanks,
--
-José
Hi Michael,
I think it's a good idea. Only "official" branches should exist in the
upstream repo.
I guess the only exception would be if a massive feature would be done by
different individuals collaborating and they would need a "neutral" place
for the branch to be. But This didn't happen yet
+1
Should be fine to just delete all of them (as long as nobody raised
objections).
Not sure if we could enable some protection GitHub side that disallow to
push into non-existing branches and thus avoids accidental branch creation?
-Matthias
On 3/13/24 11:39 AM, Josep Prat wrote:
Hi
Hello,
We currently use short lived TLS certs for our CruiseControlMetricsReporter
which is creating issues when the cert reloads the producer client is
failing to restart as well. A rolling restart resolves this but I was
hoping to find out if there is a dynamic way to reload these producers or
Thanks Manikumar!
+1
Best,
Bruno
On 3/13/24 5:56 PM, Josep Prat wrote:
+1 thanks for volunteering!
Best
---
Josep Prat
Open Source Engineering Director, aivenjosep.p...@aiven.io |
+491715557497 | aiven.io
Aiven Deutschland GmbH
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari
There seems to be open issue in Gradle for it:
https://github.com/gradle/gradle/issues/20854
>Monday, March 4, 2024 9:44 PM UTC from Pavel Pozdeev
>
>
>Hi team,
>I'm a new member, just joined the community. Trying to add Kraft support to
>some existing unit-tests.
>I noticed, that when
+1, Thanks Manikumar!
On Thu, Mar 14, 2024 at 3:40 AM Bruno Cadonna wrote:
> Thanks Manikumar!
>
> +1
>
> Best,
> Bruno
>
> On 3/13/24 5:56 PM, Josep Prat wrote:
> > +1 thanks for volunteering!
> >
> > Best
> > ---
> >
> > Josep Prat
> > Open Source Engineering Director,
Thanks for the feedback Bruno, Matthias, and Lucas!
There is a decent amount but I'm going to try and just hit the major points
as I would like to keep this change simple.
I've made corrections for the mistakes pointed out. Thanks for the
suggestions everyone.
The main sticking point seems to
35 matches
Mail list logo