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
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
>
> 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
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
+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
+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
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
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
+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
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
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
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,
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
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
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
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
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
+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
+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
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
>
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
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
[
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
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
+ 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 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 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
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
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
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
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
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.
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
35 matches
Mail list logo
