In light of the recent blockers that were reported in the past few days I'm
now closing RC1.
These blockers have now been resolved and RC2 is almost ready, so I will
start a new thread for this new release candidate.
Many thanks to everyone who tested RC1.
Konstantine
On Tue, Aug 31, 2021 at 6:3
Thanks David.
Also, somehow I missed Rajini's email on KAFKA-13277. In any case, thanks
Rajini and Colin for fixing this blocker too.
Konstantine
On Wed, Sep 8, 2021 at 7:46 PM David Jacot
wrote:
> Hi Konstantine,
>
> FYI, we just merged https://issues.apache.org/jira/browse/KAFKA-13266 to
>
Hi Konstantine,
FYI, we just merged https://issues.apache.org/jira/browse/KAFKA-13266 to
trunk and to 3.0.
Best,
David
On Tue, Sep 7, 2021 at 11:25 PM Konstantine Karantasis <
kkaranta...@apache.org> wrote:
> Thanks for raising this Colin.
>
> https://issues.apache.org/jira/browse/KAFKA-13277
>
Thanks for raising this Colin.
https://issues.apache.org/jira/browse/KAFKA-13277
is a one line fix with a test now. The suggestion to include it in RC2
makes sense to me as well. I’ll make sure it’s in.
Konstantine
On Tue, Sep 7, 2021 at 11:42 PM Colin McCabe wrote:
> Hi Konstantine,
>
> Give
Hi Konstantine,
Given that we are making a new RC, I would suggest that we merge "KAFKA-13277;
Fix size calculation for tagged string fields in message generator" to 3.0.
What do you think?
best,
Colin
On Tue, Sep 7, 2021, at 13:20, Konstantine Karantasis wrote:
> Thanks David,
>
> Assuming
Thanks David,
Assuming we'll have the PRs you mention merged soon, I'll include them in
RC2 for 3.0.0 given their low risk and the fact that we need to generate a
new RC anyways.
Konstantine
On Tue, Sep 7, 2021 at 4:43 PM David Jacot
wrote:
> Hi Konstantine,
>
> I would like to propose https:/
Thanks for clarifying Ismael.
In that case, your proposed change sounds good to include in RC2 as well.
Konstantine
On Tue, Sep 7, 2021 at 4:27 PM Ismael Juma wrote:
> Hi Konstantine,
>
> I will remove the final modifier for now.
>
> I added it because the removal of the deprecated `close` ov
Hi Konstantine,
I would also like to include
https://issues.apache.org/jira/browse/KAFKA-13277 in 3.0 as a blocker. It
is a small fix, will submit PR today.
Thank you,
Rajini
On Tue, Sep 7, 2021 at 2:43 PM David Jacot
wrote:
> Hi Konstantine,
>
> I would like to propose https://github.com/ap
Hi Konstantine,
I would like to propose https://github.com/apache/kafka/pull/11300 as a
blocker
as well. The PR fixes KAFKA-13258/13259/13260. There are all very small but
annoying issues. The PR is trivial.
Regarding KAFKA-13266, the fix is quite simple, so low risk in my opinion.
Jason
will rev
Hi Konstantine,
I will remove the final modifier for now.
I added it because the removal of the deprecated `close` overload could
lead to weird behavior if the no-args `close` was overridden (the
implementation of the no-arg `close` delegated to the removed `close`, but
that's no longer the case
Regarding the documentation link which I forgot to answer above, docs are
currently not deployed during preview. The link is generated in this
templated format while running the release scripts.
Gary, for now, you may find the docs for AK 3.0 in:
https://home.apache.org/~kkarantasis/kafka-3.0.0-rc
Hi Tom,
It'd be good to avoid a breaking change in a subsequent release that is
related to the modernization of KafkaFuture. Avoiding to use a reference to
an non-public implementation class in the public interfaces seems to help
us with that, as you observed. I'm approving KAFKA-13276 to be inclu
Hi Gary,
Regarding KAFKA-13262, this might need a more detailed and strong
justification to be considered as a blocker at this point in the release.
But we are already moving towards RC2 because of the blockers mentioned
above, so I'd be in favor of a PR that would revert the change that made
this
Hi David,
Thanks for discovering the issue reported in KAFKA-13266. I'm tentatively
approving it if we can review the PR this week, since we are going to have
a new RC due to KAFKA-13270 anyways. This is not a change of a few lines of
code though and while most of it seems to be shuffling around e
Hi Ron,
Thanks for reporting this issue. KAFKA-13270 is an obvious regression from
previous versions, so the fix - that I now see has been merged already - is
approved for inclusion in 3.0.0 and I'll add it to the next release
candidate that we'll need to generate for 3.0.0.
Konstantine
On Fri,
Hi Magnus,
Thanks for reporting the numbers.
I agree that what you observe warrants further investigation, not so much
because these are clear performance regressions but because they might be
indications of underlying issues, as you noted. However, from a major
release standpoint I'd say that su
rowse/KAFKA-13262
> [2]: https://kafka.apache.org/30/documentation.html
>
> From: Ron Dagostino
> Sent: Thursday, September 2, 2021 9:16 PM
> To: dev@kafka.apache.org
> Cc: Users ; kafka-clients <
> kafka-clie...@googlegroups.com>
> Subject: [Susp
@kafka.apache.org
Cc: Users ; kafka-clients
Subject: [Suspected Spam] Re: [VOTE] 3.0.0 RC1
Hi Konstantine. I have opened a probable blocker ticket
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FKAFKA-13270&data=04%7C01%7Cgrussell%40vmware
Hi Konstantine,
I'd like to raise a potential blocker:
https://issues.apache.org/jira/browse/KAFKA-13266.
When this bug is hit, the partition remains failed until the broker is
restated or
the partition is updated (e.g. its epoch is bumped). It only affects the
KRaft mode.
The PR is ready: https
Hi Konstantine. I have opened a probable blocker ticket
https://issues.apache.org/jira/browse/KAFKA-13270. I will work on a PR
shortly. The description on that ticket is as follows:
The implementation of https://issues.apache.org/jira/browse/ZOOKEEPER-3593 in
ZooKeeper version 3.6.0 decreased t
Magnus,
Please could you share the machine and network specs?
How much CPU, RAM is available on each node?
What JDK, JRE version are you using?
What are your broker and client configuration values? Please could you
share this info if possible?
Thanks.
On Wed, Sep 1, 2021 at 10:25 AM Magnus
Hi Konstantine,
Some findings from running 3.0.0-RC1 with the librdkafka test suite:
* Compaction seems to take slightly longer to kick in when segment sizes
exceed their threshold. (Used to take less than 20 seconds, now takes
20..30 seconds.)
* CreateTopic seems to take slightly longer to pr
Small correction to my previous email.
The actual link for public preview of the 3.0.0 blog post draft is:
https://blogs.apache.org/preview/kafka/?previewEntry=what-s-new-in-apache6
(see also the email thread with title: [DISCUSS] Please review the 3.0.0
blog post)
Best,
Konstantine
On Tue, Aug
Hello Kafka users, developers and client-developers,
This is the second release candidate for Apache Kafka 3.0.0.
It corresponds to a major release that includes many new features,
including:
* The deprecation of support for Java 8 and Scala 2.12.
* Kafka Raft support for snapshots of the metadat
24 matches
Mail list logo