Hi Igor,
thanks a lot!
+1
Lucas
On Thu, May 16, 2024 at 5:21 AM Luke Chen wrote:
>
> Hi Igor,
>
> Thanks for volunteering!
> +1
>
> Luke
>
> On Wed, May 15, 2024 at 11:15 PM Mickael Maison
> wrote:
>
> > Hi Igor,
> >
> > Thanks for volunteering, +1
> >
> > Mickael
> >
> > On Thu, Apr 25, 2024
Hi Nick,
you are still referring to oldest-open-iterator-age-ms in the
`Proposed Changes` section.
Cheers,
Lucas
On Thu, May 2, 2024 at 4:00 PM Lucas Brutschy wrote:
>
> Hi Nick!
>
> I agree, the age variant is a bit nicer since the semantics are very
> clear from the name. If
Hi Nick!
Thanks for the KIP.
+1 (binding)
On Tue, May 14, 2024 at 5:16 PM Nick Telford wrote:
>
> Hi everyone,
>
> I'd like to call a vote on the Kafka Streams KIP-989: RocksDB Iterator
> Metrics:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-989%3A+RocksDB+Iterator+Metrics
>
> All
Thanks for the KIP!
+1 binding
On Tue, May 14, 2024 at 2:44 PM Frédérik Rouleau
wrote:
>
> Hi all,
>
> I will keep the vote open for a few more hours as I would like to propose
> the KIP for the next 3.8.0 release (deadline is the 15th May).
> Currently we have +4 binding and +3 non-binding.
>
Hi,
thanks for the KIP!
+1 (binding)
Best,
Lucas
On Tue, May 7, 2024 at 9:37 AM Bruno Cadonna wrote:
>
> Thanks for the KIP!
>
> Looking forward to a well-structured task assignor!
>
> +1 (binding)
>
> Best,
> Bruno
>
> On 5/3/24 2:44 AM, Matthias J. Sax wrote:
> > I left one more nit on the
f metrics agreed upon in
> > >>>>> that timeframe!
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Oct 24, 2023 at 6:35 AM Nick Telford > >
> > >>>> wrote:
> > >>>>&g
Hi,
Looks like a great KIP to me!
I'm late, so I'm only going to comment on the last open point 117. I'm
against any fallbacks like "use the default assignor if the custom
assignment is invalid", as it's just going to hide bugs. For the 4
cases mentioned by Sophie:
117a) I'd fail immediately
[
https://issues.apache.org/jira/browse/KAFKA-16103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-16103.
Resolution: Fixed
> Review client logic for triggering offset commit callba
Lucas Brutschy created KAFKA-16599:
--
Summary: Always await async commit callbacks in commitSync and
close
Key: KAFKA-16599
URL: https://issues.apache.org/jira/browse/KAFKA-16599
Project: Kafka
Hi!
Thanks for the KIP, great stuff.
L1. I was a bit confused that the default configuration (once you set
a DLQ topic) is going to be fail-and-send-to-DLQ, if I understood
correctly. Is this something that will be a common use-case, and is it
a configuration that we want to encourage? It
Congrats!
On Thu, Apr 18, 2024 at 6:50 PM Justine Olshan
wrote:
>
> Congratulations Greg!
>
> On Thu, Apr 18, 2024 at 12:03 AM Matthias J. Sax wrote:
>
> > Congrats Greg!
> >
> > On 4/15/24 10:44 AM, Hector Geraldino (BLOOMBERG/ 919 3RD A) wrote:
> > > Congrats! Well deserved
> > >
> > > From:
Hey Alieh,
some comments:
* "Compatibility" section wasn't clear to me. Are we just introducing
the interfaces or are we changing the default behavior? If so, that
should be explained in more detail.
* If we are introducing a new interface `ClientExceptionHandler`, what
is it going to be used
+1 (binding)
Thanks, Lucia!
On Wed, Apr 3, 2024 at 11:35 PM Sophie Blee-Goldman
wrote:
>
> +1 (binding)
>
> Thanks Lucia!
>
> On Tue, Apr 2, 2024 at 12:23 AM Matthias J. Sax wrote:
>
> > +1 (binding)
> >
> >
> > -Matthias
> >
> > On 4/1/24 7:44 PM, Lucia Cerchie wrote:
> > > Hello everyone,
>
Congrats!
On Tue, Mar 26, 2024 at 2:44 PM Federico Valeri wrote:
>
> Congrats!
>
> On Tue, Mar 26, 2024 at 2:27 PM Mickael Maison
> wrote:
> >
> > Congratulations Christo!
> >
> > On Tue, Mar 26, 2024 at 2:26 PM Chia-Ping Tsai wrote:
> > >
> > > Congrats Christo!
> > >
> > > Chia-Ping
with great power
> comes great responsibility for the users :)
>
> But this actually highlights a different aspect: the overload not
> accepting a custom `Processor` but using a built-in processor, should
> not accept a generic `StoreBuilder` but should restrict the type to
> `Sto
Hey Walker
Thanks for the KIP, and congrats on the KiBiKIP ;)
My main point is that I'd vote against introducing
`reprocessOnRestore`. The behavior for `reprocessOnRestore = false` is
just incorrect and should be removed or deprecated. If we think we
need to keep the old behavior around,
[
https://issues.apache.org/jira/browse/KAFKA-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-16008.
Resolution: Duplicate
> Fix PlaintextConsumerTest.testMaxPollInterva
[
https://issues.apache.org/jira/browse/KAFKA-16010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-16010.
Resolution: Duplicate
>
Lucas Brutschy created KAFKA-16290:
--
Summary: Investigate propagating subscription state updates via
queues
Key: KAFKA-16290
URL: https://issues.apache.org/jira/browse/KAFKA-16290
Project: Kafka
Lucas Brutschy created KAFKA-16284:
--
Summary: Performance regression in RocksDB
Key: KAFKA-16284
URL: https://issues.apache.org/jira/browse/KAFKA-16284
Project: Kafka
Issue Type: Task
[
https://issues.apache.org/jira/browse/KAFKA-16167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy reopened KAFKA-16167:
> Fix PlaintextConsumerTest.testAutoCommitOnCloseAfterWak
Lucas Brutschy created KAFKA-16248:
--
Summary: Kafka consumer should cache leader offset ranges
Key: KAFKA-16248
URL: https://issues.apache.org/jira/browse/KAFKA-16248
Project: Kafka
Issue
[
https://issues.apache.org/jira/browse/KAFKA-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-16220.
Resolution: Fixed
> KTableKTableForeignKeyInnerJoinCustomPartitionerIntegrationT
[
https://issues.apache.org/jira/browse/KAFKA-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-14384.
Resolution: Fixed
> Flaky T
[
https://issues.apache.org/jira/browse/KAFKA-14385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-14385.
Resolution: Fixed
> Flaky T
[
https://issues.apache.org/jira/browse/KAFKA-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-8691.
---
Resolution: Fixed
> Flakey test
> ProcessorConte
[
https://issues.apache.org/jira/browse/KAFKA-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-9897.
---
Resolution: Fixed
> Flaky Test StoreQueryIntegrationT
Lucas Brutschy created KAFKA-16220:
--
Summary:
KTableKTableForeignKeyInnerJoinCustomPartitionerIntegrationTest#shouldThrowIllegalArgumentExceptionWhenCustomPartionerReturnsMultiplePartitions
flaky
Key: KAFKA-16220
Hi Matthiases,
I know Scala 2 fairly well, so I'd be happy to review changes that add
Scala 3 support. However, as Matthias S. said, it has to be driven by
people who use Scala day-to-day, since I believe most Kafka Streams
committers are working with Java.
Rewriting the tests to not use
Lucas Brutschy created KAFKA-16198:
--
Summary: Reconciliation may lose partitions when topic metadata is
delayed
Key: KAFKA-16198
URL: https://issues.apache.org/jira/browse/KAFKA-16198
Project: Kafka
Lucas Brutschy created KAFKA-16169:
--
Summary: FencedException in commitAsync not propagated without
callback
Key: KAFKA-16169
URL: https://issues.apache.org/jira/browse/KAFKA-16169
Project: Kafka
Lucas Brutschy created KAFKA-16155:
--
Summary: Investigate testAutoCommitIntercept
Key: KAFKA-16155
URL: https://issues.apache.org/jira/browse/KAFKA-16155
Project: Kafka
Issue Type: Bug
Lucas Brutschy created KAFKA-16133:
--
Summary: Commits during reconciliation always time out
Key: KAFKA-16133
URL: https://issues.apache.org/jira/browse/KAFKA-16133
Project: Kafka
Issue Type
[
https://issues.apache.org/jira/browse/KAFKA-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-16097.
Resolution: Fixed
> State updater removes task without pending action in EO
[
https://issues.apache.org/jira/browse/KAFKA-15941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15941.
Resolution: Cannot Reproduce
> Flaky test: shouldRestoreNullRec
Lucas Brutschy created KAFKA-16098:
--
Summary: State updater may attempt to resume a task that is not
assigned anymore
Key: KAFKA-16098
URL: https://issues.apache.org/jira/browse/KAFKA-16098
Project
Lucas Brutschy created KAFKA-16097:
--
Summary: State updater removes task without pending action in EOSv2
Key: KAFKA-16097
URL: https://issues.apache.org/jira/browse/KAFKA-16097
Project: Kafka
Hi,
we have fixed one memory leak in Kafka Streams, but there is still at
least one missing in the code. I created
https://issues.apache.org/jira/browse/KAFKA-16089 which is a blocker.
Cheers,
Lucas
On Sun, Jan 7, 2024 at 12:05 PM Apoorv Mittal wrote:
>
> Hi Colin,
> Thanks for the response.
Lucas Brutschy created KAFKA-16089:
--
Summary: Kafka Streams still leaking memory in 3.7
Key: KAFKA-16089
URL: https://issues.apache.org/jira/browse/KAFKA-16089
Project: Kafka
Issue Type
Lucas Brutschy created KAFKA-16086:
--
Summary: Kafka Streams has RocksDB native memory leak
Key: KAFKA-16086
URL: https://issues.apache.org/jira/browse/KAFKA-16086
Project: Kafka
Issue Type
Lucas Brutschy created KAFKA-16077:
--
Summary: State updater fails to close task when input partitions
are updated
Key: KAFKA-16077
URL: https://issues.apache.org/jira/browse/KAFKA-16077
Project
Thanks for all the work that has already been done on this in the past days!
Have we considered running our test suite with
-XX:+HeapDumpOnOutOfMemoryError and uploading the heap dumps as
Jenkins build artifacts? This could speed up debugging. Even if we
store them only for a day and do it only
Congratulations, Divij!
On Fri, Dec 29, 2023 at 1:32 AM Colin McCabe wrote:
>
> Congratulations, Divij!
>
> best,
> Colin
>
> On Thu, Dec 28, 2023, at 11:38, Bruno Cadonna wrote:
> > Congratulations Divij! Well deserved!
> >
> > Best,
> > Bruno
> >
> > On 12/27/23 12:45 PM, Luke Chen wrote:
> >>
[
https://issues.apache.org/jira/browse/KAFKA-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15696.
Resolution: Fixed
> Revoke partitions on Consumer.cl
[
https://issues.apache.org/jira/browse/KAFKA-15548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15548.
Resolution: Fixed
> Send GroupConsumerHeartbeatRequest on Consumer.cl
Lucas Brutschy created KAFKA-16001:
--
Summary: Migrate ConsumerNetworkThreadTestBuilder away from
ConsumerTestBuilder
Key: KAFKA-16001
URL: https://issues.apache.org/jira/browse/KAFKA-16001
Project
Lucas Brutschy created KAFKA-16000:
--
Summary: Migrate MembershipManagerImpl away from
ConsumerTestBuilder
Key: KAFKA-16000
URL: https://issues.apache.org/jira/browse/KAFKA-16000
Project: Kafka
Lucas Brutschy created KAFKA-15999:
--
Summary: Migrate HeartbeatRequestManagerTest away from
ConsumerTestBuilder
Key: KAFKA-15999
URL: https://issues.apache.org/jira/browse/KAFKA-15999
Project: Kafka
Lucas Brutschy created KAFKA-15977:
--
Summary: DelegationTokenEndToEndAuthorizationWithOwnerTest leaks
threads
Key: KAFKA-15977
URL: https://issues.apache.org/jira/browse/KAFKA-15977
Project: Kafka
Hi Alieh,
I think we do not have to restrict ourselves too much for the future
and complicate the implementation. The user can always store away and
sort, so we should only provide the ordering guarantee we can provide
efficiently, and we shouldn't restrict our future evolution too much
by this.
Lucas Brutschy created KAFKA-15967:
--
Summary: Fix revocation in reconcilation logic
Key: KAFKA-15967
URL: https://issues.apache.org/jira/browse/KAFKA-15967
Project: Kafka
Issue Type: Sub
[
https://issues.apache.org/jira/browse/KAFKA-15690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15690.
Resolution: Fixed
> EosIntegrationTest is fl
[
https://issues.apache.org/jira/browse/KAFKA-15887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15887.
Resolution: Fixed
> Autocommit during close consistently fails with except
Lucas Brutschy created KAFKA-15930:
--
Summary: Flaky test - testWithGroupId - TransactionsBounceTest
Key: KAFKA-15930
URL: https://issues.apache.org/jira/browse/KAFKA-15930
Project: Kafka
Lucas Brutschy created KAFKA-15929:
--
Summary: Flaky test -
testDescribeUnderReplicatedPartitionsWhenReassignmentIsInProgress -
TopicCommandIntegrationTest
Key: KAFKA-15929
URL: https://issues.apache.org/jira
Lucas Brutschy created KAFKA-15928:
--
Summary: Flaky test - testBalancePartitionLeaders -
QuorumControllerTest
Key: KAFKA-15928
URL: https://issues.apache.org/jira/browse/KAFKA-15928
Project: Kafka
Lucas Brutschy created KAFKA-15927:
--
Summary: Flaky test - testReplicateSourceDefault -
MirrorConnectorsIntegrationExactlyOnceTest
Key: KAFKA-15927
URL: https://issues.apache.org/jira/browse/KAFKA-15927
Lucas Brutschy created KAFKA-15926:
--
Summary: Flaky test - testReplicateSourceDefault -
MirrorConnectorsIntegrationSSLTest
Key: KAFKA-15926
URL: https://issues.apache.org/jira/browse/KAFKA-15926
Lucas Brutschy created KAFKA-15925:
--
Summary: Flaky test testReplicateSourceDefault -
MirrorConnectorsIntegrationTransactionsTest
Key: KAFKA-15925
URL: https://issues.apache.org/jira/browse/KAFKA-15925
[
https://issues.apache.org/jira/browse/KAFKA-15544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15544.
Resolution: Fixed
> Enable existing client integration tests for new proto
Lucas Brutschy created KAFKA-15916:
--
Summary: Flaky test -
testClientSideTimeoutAfterFailureToReceiveResponse - KafkaAdminClientTest
Key: KAFKA-15916
URL: https://issues.apache.org/jira/browse/KAFKA-15916
Lucas Brutschy created KAFKA-15915:
--
Summary: Flaky test - testUnrecoverableError -
ProducerIdManagerTest
Key: KAFKA-15915
URL: https://issues.apache.org/jira/browse/KAFKA-15915
Project: Kafka
Lucas Brutschy created KAFKA-15914:
--
Summary: Flaky test -
testAlterSinkConnectorOffsetsOverriddenConsumerGroupId -
OffsetsApiIntegrationTest
Key: KAFKA-15914
URL: https://issues.apache.org/jira/browse/KAFKA
[
https://issues.apache.org/jira/browse/KAFKA-14624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-14624.
Resolution: Fixed
> State restoration is broken with standby tasks and cache-enab
[
https://issues.apache.org/jira/browse/KAFKA-15798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15798.
Resolution: Fixed
Test disabled in https://github.com/apache/kafka/pull/14830 since
[
https://issues.apache.org/jira/browse/KAFKA-14014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-14014.
Resolution: Fixed
Test disabled since feature will be removed.
> Flaky t
[
https://issues.apache.org/jira/browse/KAFKA-13531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-13531.
Resolution: Fixed
Test disabled since feature will be removed.
> Flaky t
Lucas Brutschy created KAFKA-15887:
--
Summary: Autocommit during close consistently fails with exception
in background thread
Key: KAFKA-15887
URL: https://issues.apache.org/jira/browse/KAFKA-15887
Hi Alieh,
thanks for the KIP!
+1 (binding)
Lucas
On Tue, Nov 21, 2023 at 11:26 AM Alieh Saeedi
wrote:
>
> Thanks, Matthias; I changed it to `ANY` which is the shortest and not
> misleading.
>
> Cheers,
> Alieh
>
> On Mon, Nov 20, 2023 at 7:42 PM Matthias J. Sax wrote:
>
> > Adding an enum is
Lucas Brutschy created KAFKA-15833:
--
Summary: Restrict Consumer API to be used from one thread
Key: KAFKA-15833
URL: https://issues.apache.org/jira/browse/KAFKA-15833
Project: Kafka
Issue
Hi Alieh,
I agree with Bruno that a weaker guarantee could be useful already,
and it's anyway possible to strengthen the guarantees later on. On the
other hand, it would be nice to provide a consistent view across all
segments if it doesn't come with major downsides, because until now IQ
does
Hi Nick,
really happy with the final KIP. Thanks a lot for the hard work!
+1 (binding)
Lucas
On Mon, Nov 13, 2023 at 4:20 PM Colt McNealy wrote:
>
> +1 (non-binding).
>
> Thank you, Nick, for making all of the changes (especially around the
> `default.state.isolation.level` config).
>
> Colt
Hi Hanyu,
Thanks for the KIP!
+1 (binding)
Cheers
Lucas
On Thu, Nov 2, 2023 at 10:19 PM Hao Li wrote:
>
> Hi Hanyu,
>
> Thanks for the KIP!
> +1 (non-binding)
>
> Hao
>
> On Thu, Nov 2, 2023 at 1:29 PM Bill Bejeck wrote:
>
> > Hi Hanyu,
> >
> > Thanks for the KIP this LGTM.
> > +1 (binding)
>
[
https://issues.apache.org/jira/browse/KAFKA-15326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15326.
Resolution: Implemented
> Decouple Processing Thread from Polling Thr
Congrats!
On Fri, Oct 27, 2023 at 5:06 PM Manikumar wrote:
>
> Congrats!
>
> On Fri, Oct 27, 2023 at 8:35 PM Jun Rao wrote:
>
> > Hi, Everyone,
> >
> > Satish Duggana has been a Kafka committer since 2022. He has been very
> > instrumental to the community since becoming a committer. It's my
Hi Hanyu,
reading the KIP, I was wondering the same thing as Bill.
Other than that, this looks good to me. Thanks for KIP.
nit: you have method names `LowerBound` and `UpperBound`, where you
probably want to fix the capitalization.
Cheers,
Lucas
On Mon, Oct 23, 2023 at 5:46 PM Bill Bejeck
so wiping state on
> timeouts.
>
> Regards,
> Nick
>
> On Wed, 18 Oct 2023 at 14:48, Lucas Brutschy
> wrote:
>
> > Hi Nick,
> >
> > I think indeed the better behavior would be to retry commitTransaction
> > until we risk running out of time t
node, because
> each time that Iterator is used, it will leak another one. So even in the
> presence of many non-leaky Iterators on a busy instance, the metric should
> still consistently climb.
>
> Regards,
>
> Nick
>
> On Mon, 16 Oct 2023 at 14:24, Lucas Brutschy
> wrote:
gt; logical, but what if it times out again? Where do we draw the line and
> shutdown the instance?
>
> Regards,
> Nick
>
> On Mon, 16 Oct 2023 at 13:19, Lucas Brutschy
> wrote:
>
> > Hi all,
> >
> > I think I liked your suggestion of allowing EOS wi
+1 (binding)
Thanks for the KIP!
On Tue, Oct 17, 2023 at 2:31 AM Matthias J. Sax wrote:
>
> +1 (binding)
>
>
> On 10/13/23 9:24 AM, Hanyu (Peter) Zheng wrote:
> > Hello everyone,
> >
> > I would like to start a vote for KIP-985 that Add reverseRange and
> > reverseAll query over kv-store in
Hi Nick!
thanks for the KIP! I think this could be quite useful, given the
problems that we had with leaks due to RocksDB resources not being
closed.
I don't have any pressing issues why we can't accept it like it is,
just one minor point for discussion: would it also make sense to make
it
t; >>>>> be
> > > > >>>>>>> to add something like: ReadOnlyKeyValueStore
> > > > >>>>>>> readOnlyView(IsolationLevel isolationLevel) to
> > > > ReadOnlyKeyValueStore
> > > >
Hi,
thanks again for the KIP!
+1 (binding)
Cheers,
Lucas
On Sun, Oct 15, 2023 at 9:13 AM Colt McNealy wrote:
>
> Hello there,
>
> I'd like to call a vote on KIP-988 (co-authored by my friend and colleague
> Eduwer Camacaro). We are hoping to get it in before the 3.7.0 release.
>
>
Hi all,
it's a nice improvement! I don't have anything to add on top of the
previous comments, just came here to say that it seems to me consensus
has been reached and the result looks good to me.
Thanks Colt and Eduwer!
Lucas
On Sun, Oct 15, 2023 at 9:11 AM Colt McNealy wrote:
>
> Thanks,
+1 (binding)
Thanks for the KIP!
Cheers,
Lucas
On Wed, Oct 11, 2023 at 7:55 PM Walker Carlson
wrote:
>
> +1 (binding)
>
> Thanks for the kip Alieh!
>
> Walker
>
> On Wed, Oct 11, 2023 at 3:52 AM Bruno Cadonna wrote:
>
> > Thanks for the KIP, Alieh!
> >
> > +1 (binding)
> >
> > Best,
> > Bruno
Hi Hanyu,
Thanks a lot for the KIP! I agree with Bruno's comments about fluent
API / keeping the query classes immutable. Apart from that, on the
technical side this is looking good already!
Two comments on the KIP itself (not the technical part):
- The motivation section could be extended by a
Congrats, Justine!
On Mon, Sep 25, 2023 at 9:20 AM Bruno Cadonna wrote:
>
> Congrats, Justine! Well deserved!
>
> Best,
> Bruno
>
> On 9/25/23 5:28 AM, ziming deng wrote:
> > Congratulations Justine!
> >
> >
> >> On Sep 25, 2023, at 00:01, Viktor Somogyi-Vass
> >> wrote:
> >>
> >> Congrats
[
https://issues.apache.org/jira/browse/KAFKA-15463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-15463.
Resolution: Not A Problem
> StreamsException: Accessing from an unknown n
Hi Nick,
since I last read it in April, the KIP has become much cleaner and
easier to read. Great work!
It feels to me the last big open point is whether we can implement
isolation level as a query parameter. I understand that there are
implementation concerns, but as Colt says, it would be a
Lucas Brutschy created KAFKA-15378:
--
Summary: Rolling upgrade system tests are failing
Key: KAFKA-15378
URL: https://issues.apache.org/jira/browse/KAFKA-15378
Project: Kafka
Issue Type
+1 (non-binding)
On Fri, Aug 11, 2023 at 1:08 AM Matthias J. Sax wrote:
>
> +1 (binding)
>
> On 8/10/23 12:31 PM, Florin Akermann wrote:
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-962%3A+Relax+non-null+key+requirement+in+Kafka+Streams
> >
Lucas Brutschy created KAFKA-15326:
--
Summary: Decouple Processing Thread from Polling Thread
Key: KAFKA-15326
URL: https://issues.apache.org/jira/browse/KAFKA-15326
Project: Kafka
Issue
Hi Alieh,
thanks a lot for the KIP. IQ with time semantics is going to be
another great improvement towards having crystal clear streaming
semantics!
1. I agree with Bruno and Matthias, to remove the 'bound' term for the
timestamps. It's confusing that we have bounds for both timestamps and
Hi Florin,
thanks for the KIP! This looks good to me. I agree that the precise
Java doc wording doesn't have to be discussed as part of the KIP.
I would also suggest to include an update to
https://kafka.apache.org/documentation/streams/upgrade-guide
Cheers,
Lucas
On Mon, Aug 7, 2023 at 10:51
[
https://issues.apache.org/jira/browse/KAFKA-14278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-14278.
Resolution: Fixed
> Convert INVALID_PRODUCER_EPOCH into PRODUCER_FENCED TxnOffsetCom
Congrats!!
On Wed, Jun 14, 2023 at 11:02 AM Federico Valeri wrote:
>
> Congrats Divij!
>
> On Wed, Jun 14, 2023 at 10:02 AM Divij Vaidya wrote:
> >
> > Thank you everyone! I promise to shoulder this new responsibility to the
> > best of my abilities.
> >
> > --
> > Divij Vaidya
> >
> >
> >
> >
Hi Walker,
+1 (non-binding)
Cheers,
Lucas
On Mon, Jun 5, 2023 at 4:20 PM Bruno Cadonna wrote:
>
> Hi Walker,
>
> Thank you for the KIP!
>
> +1 (binding)
>
> Best,
> Bruno
>
> On 24.05.23 23:00, Walker Carlson wrote:
> > Hello everybody,
> >
> > I'm opening the vote on KIP-923 here
> >
On 5/2/23 2:06 PM, Victoria Xia wrote:
> > > > Cool KIP, Walker! Thanks for sharing this proposal.
> > > >
> > > > A few clarifications:
> > > >
> > > > 1. Is the order that records exit the buffer in necessarily the same as
&
HI Walker,
thanks for the KIP! We definitely need this. I have two questions:
- Have you considered allowing the customization of the underlying
buffer implementation? As I can see, `StreamJoined` lets you customize
the underlying store via a `WindowStoreSupplier`. Would it make sense
for
[
https://issues.apache.org/jira/browse/KAFKA-14172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy resolved KAFKA-14172.
Resolution: Fixed
> bug: State stores lose state when tasks are reassigned under EOS
1 - 100 of 121 matches
Mail list logo
