ction is not enabled, the other replicas may not become the
> > > leader right ?
> > >
> > > It is not clear to me whether Solution 2 can happen independently. For
> > > example, if the leader exceeds *leader.fetch.process.time.max.ms
> > > <http://leader.fetch.
Detecting that a leader is slow cannot be determined by just
> one occurrence, right ?
>
> Thanks
> Mohan
>
>
> On Sun, Jun 27, 2021 at 4:01 AM Satish Duggana
> wrote:
>
> > Hi Dhruvil,
> > Thanks for looking into the KIP and providing your commen
Hi Dhruvil,
Thanks for looking into the KIP and providing your comments.
There are two problems about the scenario raised in this KIP:
a) Leader is slow and it is not available for reads or writes.
b) Leader is causing the followers to be out of sync and cause the
partitions unavailability.
(a)
Satish Duggana created KAFKA-12988:
--
Summary: RLMM add/updateRemoteLogSegmentMetadata and
putRemotePartitionDeleteMetadata to be changed with asynchronous APIs.
Key: KAFKA-12988
URL: https://issues.apache.org
Hi,
Bumping up the discussion thread on KIP-501 about avoiding out-of-sync or
offline partitions when follower fetch requests are not processed in time
by the leader replica. This issue occurred several times in multiple
production environments (at Uber, Yelp, Twitter, etc).
KIP-501 is located
Hi Jun,
I updated the KIP-501 with more details. Please take a look and
provide your comments.
This issue occurred several times in multiple production
environments(Uber, Yelp, Twitter, etc).
Thanks,
Satish.
On Thu, 13 Feb 2020 at 17:04, Satish Duggana wrote:
>
> Hi Lucas,
&g
Congratulations Konstantine!!
On Tue, 22 Jun 2021 at 00:34, Bill Bejeck wrote:
> Congrats Konstantine!
>
> -Bill
>
> On Mon, Jun 21, 2021 at 12:44 PM Tom Bentley wrote:
>
> > Congratulations Konstantine!
> >
> > On Mon, Jun 21, 2021 at 5:33 PM David Jacot >
> > wrote:
> >
> > > Congrats,
Satish Duggana created KAFKA-12970:
--
Summary: Make tiered storage related schemas adopt flexible
versions feature.
Key: KAFKA-12970
URL: https://issues.apache.org/jira/browse/KAFKA-12970
Project
Satish Duggana created KAFKA-12969:
--
Summary: Add cluster or broker level config for topic level
tiered storage confgs.
Key: KAFKA-12969
URL: https://issues.apache.org/jira/browse/KAFKA-12969
+1 (non-binding)
On Tue, 8 Jun 2021 at 04:49, Konstantine Karantasis
wrote:
> +1 (binding)
>
> Konstantine
>
> On Mon, Jun 7, 2021 at 6:51 AM Josep Prat
> wrote:
>
> > Hi Ismael,
> >
> > Good KIP, it's a +1 (non binding) from my side.
> >
> > Best,
> >
> > ———
> > Josep Prat
> >
> > Aiven
+1 (non-binding)
On Mon, 7 Jun 2021 at 19:30, Dongjin Lee wrote:
> +1 (non-binding)
>
> As a note: I think the exact removal schedule may be changed.
>
> Best,
> Dongjin
>
> On Mon, Jun 7, 2021, 10:56 PM Josep Prat
> wrote:
>
> > Thanks Ismael, it's a +1 (non-binding) from my side,
> >
> >
> >
Satish Duggana created KAFKA-12816:
--
Summary: Add tier storage configs.
Key: KAFKA-12816
URL: https://issues.apache.org/jira/browse/KAFKA-12816
Project: Kafka
Issue Type: Sub-task
Satish Duggana created KAFKA-12802:
--
Summary: Add a file based cache for consumed remote log metadata
for each partition to avoid consuming again incase of broker restarts.
Key: KAFKA-12802
URL: https
Satish Duggana created KAFKA-12758:
--
Summary: Create a new `server-common` module and move
ApiMessageAndVersion, RecordSerde, AbstractApiMessageSerde, and
BytesApiMessageSerde to that module.
Key: KAFKA-12758
Satish Duggana created KAFKA-12757:
--
Summary: Move server related common classes into a separate
`server-common` module.
Key: KAFKA-12757
URL: https://issues.apache.org/jira/browse/KAFKA-12757
+1 (non-binding)
- Ran releaseTarGzAll successfully with no failures.
- Ran subset of tests.
- Ran through quickstart on builds generated from the tag.
- Ran a few internal apps targeting topics on a 5 node cluster.
Thanks,
Satish.
On Tue, 27 Apr 2021 at 02:57, Israel Ekpo wrote:
>
> +1 for
forget.
>
> Thanks,
> Jason
>
> On Mon, Apr 26, 2021 at 10:02 AM Satish Duggana
> wrote:
>
> > Hi Jason,
> > Thanks for the detailed KIP. Both the changes including the default
> > session timeout change and min/max group session timeout are great
> > impro
Hi Jason,
Thanks for the detailed KIP. Both the changes including the default
session timeout change and min/max group session timeout are great
improvements.
It is good to add this behavior in the upgrade docs. How do we track
these to be updated in the upgrade docs?
Best,
Satish.
On Sat, 24
+1 (non-binding)
- Ran releaseTarGzAll successfully with no failures.
- Ran subset of tests.
- Ran through quickstart on builds generated from the tag.
- Ran a few internal apps targeting topics on a 5 node cluster.
Thanks,
Satish.
On Sun, 18 Apr 2021 at 04:13, Colin McCabe wrote:
> Hi John,
Congratulations Randall!!
On Sat, 17 Apr, 2021, 5:29 AM Raymond Ng, wrote:
> Congrats Randall!
>
> On Fri, Apr 16, 2021 at 4:45 PM Matthias J. Sax wrote:
>
> > Hi,
> >
> > It's my pleasure to announce that Randall Hauch in now a member of the
> > Kafka PMC.
> >
> > Randall has been a Kafka
Congratulations Bill!!
On Thu, 8 Apr 2021 at 13:24, Tom Bentley wrote:
> Congratulations Bill!
>
> On Thu, Apr 8, 2021 at 2:36 AM Luke Chen wrote:
>
> > Congratulations Bill!
> >
> > Luke
> >
> > On Thu, Apr 8, 2021 at 9:17 AM Matthias J. Sax wrote:
> >
> > > Hi,
> > >
> > > It's my pleasure
Satish Duggana created KAFKA-12641:
--
Summary: Clear RemoteLogLeaderEpochState entry when it become
empty.
Key: KAFKA-12641
URL: https://issues.apache.org/jira/browse/KAFKA-12641
Project: Kafka
Congratulations, Chia-Ping, well deserved!
> > > >
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > > > On Mon, Mar 15, 2021 at 9:59 AM Bruno Cadonna
> > > > >
> > > > wrote:
> > >
Congratulations Tom!!
On Tue, 16 Mar 2021 at 13:30, David Jacot
wrote:
> Congrats, Tom!
>
> On Tue, Mar 16, 2021 at 7:40 AM Kamal Chandraprakash <
> kamal.chandraprak...@gmail.com> wrote:
>
> > Congrats, Tom!
> >
> > On Tue, Mar 16, 2021 at 8:32 AM Konstantine Karantasis
> > wrote:
> >
> > >
Hi Israel,
Thanks for your interest in tiered storage. As mentioned by Jun earlier, we
decided not to have any implementations in Apache Kafka repo like Kafka
connectors. We plan to have RSM implementations for HDFS, S3, GCP, and
Azure storages in a separate repo. We will let you know once they
Congrats Chia-Ping!
On Sat, 13 Mar 2021 at 13:34, Tom Bentley wrote:
> Congratulations Chia-Ping!
>
> On Sat, Mar 13, 2021 at 7:31 AM Kamal Chandraprakash <
> kamal.chandraprak...@gmail.com> wrote:
>
> > Congratulations, Chia-Ping!!
> >
> > On Sat, Mar 13, 2021 at 11:38 AM Ismael Juma wrote:
>
Satish Duggana created KAFKA-12429:
--
Summary: Serdes for all message types in internal topic which is
used in default implementation for RLMM.
Key: KAFKA-12429
URL: https://issues.apache.org/jira/browse/KAFKA
Satish Duggana created KAFKA-12368:
--
Summary: Inmemory implementation of RSM and RLMM.
Key: KAFKA-12368
URL: https://issues.apache.org/jira/browse/KAFKA-12368
Project: Kafka
Issue Type
t; > > wrote:
> > > > >
> > > > > > Hi Satish,
> > > > > >
> > > > > > Thanks for driving this KIP. I’m sure there will be a few tweaks as
> > > we
> > > > > > implement the KIP, but I
> > > > > > think KIP i
Hi All,
We would like to start voting on “KIP-405: Kafka Tiered Storage”.
For reference here is the KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage
Thanks,
Satish.
TODOs in the KIP. Could you please address these or
> > remove them?
> >
> > 9010. There is a reference to a Google doc on the KIP which was used
> > earlier for discussions. Please could you remove the reference, since the
> > KIP is the source of the truth?
> &
t; 9010. There is a reference to a Google doc on the KIP which was used
> earlier for discussions. Please could you remove the reference, since the
> KIP is the source of the truth?
>
> 9011. This feedback is from an earlier comment. In the RemoteStorageManager
> interface, there is an A
port. Two other remaining
> items are (a) the format of local tier metadata storage and (b) upgrade.
>
> Jun
>
> On Mon, Dec 7, 2020 at 8:56 AM Satish Duggana
> wrote:
>
> > Hi Jun,
> > Thanks for your comments. Please find the inline replies below.
> >
> &
ormats
> .
>
> 6010. remote.log.manager.thread.pool.size: The default value is 10. This
> might be too high when enabling the tiered feature for the first time.
> Since there are lots of segments that need to be tiered initially, a large
> number of threads could overwhelm the broker.
>
> 60
.
On Tue, Nov 10, 2020 at 8:26 PM Satish Duggana wrote:
>
> Hi Jun,
> Thanks for your comments. Please find the inline replies below.
>
> 605.2 "Build the local leader epoch cache by cutting the leader epoch
> sequence received from remote storage to [LSO, ELO]." I
ncerns and
> > readability). One proposal I have is to take a step back and define a
> > higher level Log interface. Then, the Broker code can be changed to use
> > this interface. It can be changed such that only a handle to the interface
> > is exposed to other components (suc
e provided (implementing the higher level Log interface)
> which will contain any/all logic surrounding tiered data. The wrapper
> class will wrap around an instance of the Log class delegating the local
> log logic to it. Finally, a handle to the wrapper class can be exposed to
> the other
Hi,
KIP is updated with 1) topic deletion lifecycle and its related items
2) Protocol changes(mainly related to ListOffsets) and other minor
changes.
Please go through them and let us know your comments.
Thanks,
Satish.
On Mon, Sep 28, 2020 at 9:10 PM Satish Duggana wrote:
>
> Hi D
Congratulations David!
On Sat, Oct 17, 2020 at 10:46 AM Boyang Chen wrote:
>
> Congrats David, well deserved!
>
> On Fri, Oct 16, 2020 at 6:45 PM John Roesler wrote:
>
> > Congratulations, David!
> > -John
> >
> > On Fri, Oct 16, 2020, at 20:15, Konstantine Karantasis wrote:
> > > Congrats,
Hi Justine,
Thanks for the KIP, +1 (non-binding)
On Thu, Oct 15, 2020 at 10:48 PM Lucas Bradstreet wrote:
>
> 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
t; > Hi All,
> >
> > We are all working through the last meeting feedback. I'll cancel the
> > tomorrow 's meeting and we can meanwhile continue our discussion in mailing
> > list. We can start the regular meeting from next week onwards.
> >
> > Thanks,
>
Thanks Lucas/Justine for the nice KIP.
It has several benefits which also include simplifying the topic
deletion process by controller and logs cleanup by brokers in corner
cases.
Best,
Satish.
On Wed, Sep 9, 2020 at 10:07 PM Justine Olshan wrote:
>
> Hello all, it's been almost a year! I've
DELETE_STARTED, DELETE_FINISHED?
>
> 610. remote.log.reader.max.pending.tasks: "Maximum remote log reader thread
> pool task queue size. If the task queue is full, broker will stop reading
> remote log segments." What does the broker do if the queue is full?
>
> 611. What do we
; > > > gmail.com > wrote:
> > > >
> > > > Hi Jun,
> > > >
> > > > Many thanks for your initiative.
> > > >
> > > > If you like, I am happy to attend at the time you suggested.
> > > >
> > >
ata (not sure). Could we make these apis asynchronous (ex:
> based on java.util.concurrent.Future) to provide room for tapping
> performance improvements such as non-blocking i/o?
>
> 5011. The same question as 5009 on sync vs async api for RSM. Have we
> considered the pros/co
ing along? To me, the two biggest
> missing items are (1) more detailed documentation on how all the new APIs
> are being used and (2) metadata format and usage in the internal
> topic __remote_log_metadata.
>
> Thanks,
>
> Jun
>
> On Tue, Aug 4, 2020 at 8:32 AM Satish
econds to keep a log file before
> deleting it". The deletion is independent of whether tiering is enabled or
> not. If this changes to just the local portion of the data, we are changing
> the meaning of an existing configuration.
>
> Jun
>
>
> On Thu, Jul 23, 2020 at
t; > > some
> > > > > > feature tests / system tests. I have added the performance test
> > > results
> > > > > in
> > > > > > the KIP. However the recent design changes (e.g. leader epoch
> info
> > > > > >
weeks for us to implement after
> > you
> > > >> review and agree with those design changes.
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Jul 7, 2020 at 9:23 AM Jun Rao wrote:
> > > >>
> > > >>
t; Any new updates on the KIP? This feature is one of the most important
> > >> and
> > >> > most requested features in Apache Kafka right now. It would be helpful
> > >> if
> > >> > we can make sustained progress on this. Could you share ho
Congratulations Xi!
On Mon, Jun 29, 2020 at 10:41 AM Konstantine Karantasis
wrote:
>
> Congrats Xi!
>
> -Konstantine
>
> On Sat, Jun 27, 2020 at 7:13 PM Matt Wang wrote:
>
> > Congratulations ~
> >
> >
> > --
> >
> > Best,
> > Matt Wang
> >
> >
> > On 06/26/2020 23:06，David Jacot wrote：
> >
Congratulations Boyang!
On Fri, Jun 26, 2020 at 8:36 PM David Jacot wrote:
>
> Congrats, Boyang!
>
> On Thu, Jun 25, 2020 at 1:57 PM Viktor Somogyi-Vass
> wrote:
>
> > Congrats :)
> >
> > On Thu, Jun 25, 2020 at 12:28 AM Liquan Pei wrote:
> >
> > > Congrats!
> > >
> > > On Wed, Jun 24, 2020 at
ed
> epoch-to-offset vectors? Or try to reconstruct its local replica
> lineage based on the data remotely available?
>
> Thanks,
> Alexandre
>
> [1]
> https://docs.google.com/document/d/18tnobSas3mKFZFr8oRguZoj_tkD_sGzivuLRlMloEMs/edit?usp=sharing
>
> Le jeu. 4 juin 2020 à
Hi Jun,
Please let us know if you have any comments on "transactional support"
and "follower requests/replication" mentioned in the wiki.
Thanks,
Satish.
On Tue, Jun 2, 2020 at 9:25 PM Satish Duggana wrote:
>
> Thanks Jun for your comments.
>
> >100. It woul
py producer-id-snapshot as we are copying only
> segments earlier to last-stable-offset." Hmm, not sure about that. The
> producer snapshot includes things like the last timestamp of each open
> producer id and can affect when those producer ids are expired.
>
> Thanks,
>
&g
Hi Jun,
Gentle reminder. Please go through the updated wiki and let us know your
comments.
Thanks,
Satish.
On Tue, May 19, 2020 at 3:50 PM Satish Duggana
wrote:
> Hi Jun,
> Please go through the wiki which has the latest updates. Google doc is
> updated frequently to be in sync
gt; the wiki or the google doc?
>
> Jun
>
> On Thu, May 14, 2020 at 10:38 AM Satish Duggana
> wrote:
>
>> Hi Jun,
>> Thanks for your comments. We updated the KIP with more details.
>>
>> >100. For each of the operations related to tiering, it would be useful
+1 (non-binding)
Thanks Anna for the nice feature to control the connection creation rate
from the clients.
On Tue, May 19, 2020 at 8:16 AM Gwen Shapira wrote:
> +1 (binding)
>
> Thank you for driving this, Anna
>
> On Mon, May 18, 2020 at 4:55 PM Anna Povzner wrote:
>
> > Hi All,
> >
> > I
s, sth like
>> preparePutRemoteLogSegmentData() and commitPutRemoteLogSegmentData().
>>
>> 103. It seems that the transactional support and the ability to read from
>> follower are missing.
>>
>> 104. It would be useful to provide a testing plan for this KIP.
&
Satish Duggana created KAFKA-9990:
-
Summary: Supporting transactions in tiered storage
Key: KAFKA-9990
URL: https://issues.apache.org/jira/browse/KAFKA-9990
Project: Kafka
Issue Type: Sub
Congrats Konstantine!!
On Thu, Feb 27, 2020 at 12:35 PM Tom Bentley wrote:
>
> Congratulations!
>
> On Thu, Feb 27, 2020 at 6:43 AM David Jacot wrote:
>
> > Congrats!
> >
> > Le jeu. 27 févr. 2020 à 06:58, Vahid Hashemian
> > a écrit :
> >
> > > Congratulations Konstantine!
> > >
> > >
Hi Jun,
Please look at the earlier reply and let us know your comments.
Thanks,
Satish.
On Wed, Feb 12, 2020 at 4:06 PM Satish Duggana wrote:
>
> Hi Jun,
> Thanks for your comments on the separation of remote log metadata
> storage and remote log storage.
> We had a few discussi
Satish Duggana created KAFKA-9579:
-
Summary: RLM fetch implementation by adding respective purgatory
Key: KAFKA-9579
URL: https://issues.apache.org/jira/browse/KAFKA-9579
Project: Kafka
Satish Duggana created KAFKA-9569:
-
Summary: RSM implementation for HDFS storage.
Key: KAFKA-9569
URL: https://issues.apache.org/jira/browse/KAFKA-9569
Project: Kafka
Issue Type: Sub-task
[
https://issues.apache.org/jira/browse/KAFKA-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Satish Duggana resolved KAFKA-9554.
---
Resolution: Duplicate
Duplicate of https://issues.apache.org/jira/browse/KAFKA-9548
Satish Duggana created KAFKA-9550:
-
Summary: RemoteLogManager implementation
Key: KAFKA-9550
URL: https://issues.apache.org/jira/browse/KAFKA-9550
Project: Kafka
Issue Type: Sub-task
Satish Duggana created KAFKA-9549:
-
Summary: Local storage implementations for RSM and RLMM which can
be used in tests.
Key: KAFKA-9549
URL: https://issues.apache.org/jira/browse/KAFKA-9549
Project
Satish Duggana created KAFKA-9548:
-
Summary: RemoteStorageManager and RemoteLogMetadataManager
interfaces.
Key: KAFKA-9548
URL: https://issues.apache.org/jira/browse/KAFKA-9548
Project: Kafka
Hi Lucas,
Thanks for looking into the KIP and providing your comments.
Adding to what Harsha mentioned, I do not think there is a fool proof
solution here to solve the cases like pending requests in the request
queue. We also thought about the option of relinquishing the
leadership but the
azonS3/latest/dev/NotificationHowTo.html).
> > > Otherwise one could use a separate metadata store that supports
> > push-based
> > > change propagation. Other people have mentioned using a Kafka topic. The
> > > best approach may depend on the object store and the operational
+1 (non-binding)
On Fri, Jan 24, 2020 at 11:10 AM Harsha Chintalapani wrote:
>
> +1 ( binding). Much needed!
> -Harsha
>
>
> On Thu, Jan 23, 2020 at 7:17 PM, Guozhang Wang wrote:
>
> > +1 （binding）
> >
> > On Thu, Jan 23, 2020 at 1:55 PM Guozhang Wang wrote:
> >
> > Yeah that makes sense, it
hanks,
> Harsha
>
>
> On Mon, Nov 18, 2019 at 7:05 PM, Satish Duggana
> wrote:
>
> > Hi Jason,
> > Thanks for looking into the KIP. Apologies for my late reply. Increasing
> > replica max lag to 30-45 secs did not help as we observed that a few fet
Hi Jun,
Thanks for your reply.
Currently, `listRemoteSegments` is called at the configured
interval(not every second, defaults to 30secs). Storing remote log
metadata in a strongly consistent store for S3 RSM is raised in
PR-comment[1].
RLM invokes RSM at regular intervals and RSM can give remote
ason
>
> On Wed, Nov 6, 2019 at 8:14 AM Satish Duggana
> wrote:
>
> > Hi Dhruvil,
> > Thanks for looking into the KIP.
> >
> > 10. I have an initial sketch of the KIP-500 in commit[a] which
> > discusses tracking the pending fetch requests. Tracking i
Hi Jun,
Thanks for your detailed review and comments.
>40. Local segment metadata storage: The KIP makes the assumption that the
metadata for the archived log segments are cached locally in every broker
and provides a specific implementation for the local storage in the
framework. We probably
+1 (non-binding), Thanks Ismael for the KIP. I believe it is time to
drop Scala 2.11.
On Mon, Nov 18, 2019 at 7:10 PM Ivan Yurchenko wrote:
>
> Do I understand correctly, that non-commiters can also vote, despite their
> votes don't decide?
>
> If so, then +1 from me.
>
> Ivan
>
>
> On Mon, 18
+1 (non-binding)
- Ran testAll/releaseTarGzAll successfully with no failures.
- Ran through quickstart of core/streams on builds generated from 2.3.0-rc2
tag.
- Ran a few internal apps with ~2500 topic-partitions on 5 a node cluster.
Thanks,
Satish.
On Sat, Nov 9, 2019 at 4:41 AM Bill Bejeck
Congratulations Mickael!!
On Fri, Nov 8, 2019 at 2:50 PM Rajini Sivaram wrote:
>
> Congratulations, Mickael, well deserved!!
>
> Regards,
>
> Rajini
>
> On Fri, Nov 8, 2019 at 9:08 AM David Jacot wrote:
>
> > Congrats Mickeal, well deserved!
> >
> > On Fri, Nov 8, 2019 at 8:56 AM Tom Bentley
+1 (non-binding)
On Thu, Nov 7, 2019 at 8:58 PM Ismael Juma wrote:
>
> +1 (binding)
>
> On Thu, Oct 24, 2019 at 9:33 PM radai wrote:
>
> > Hello,
> >
> > I'd like to initiate a vote on KIP-514.
> >
> > links:
> > the kip -
> >
t 7:55 AM Satish Duggana wrote:
>
> >Depends on the implementation, the data of one segment may not necessary be
> stored in a single file.
> There could be a maximum object / chunk / file size restriction on the
> remote storage. So, one Kafka
> segment could be saved in mul
7, 2019 at 8:33 AM Satish Duggana wrote:
>
> >So that means a consumer which gets behind by half an hour will find its
> reads being served from remote storage. And, if I understand the proposed
> algorithm, each such consumer fetch request could result in a separate
> fetch reque
>So that means a consumer which gets behind by half an hour will find its
reads being served from remote storage. And, if I understand the proposed
algorithm, each such consumer fetch request could result in a separate
fetch request from the remote storage. I.e. there's no mechanism to
amortize
eLogIndexEntry are offset index entries pointing to record
> > batches inside a segment. That seems to be the same as the .index file?
> >
> > Thanks,
> >
> > Jun
> >
> > On Mon, Oct 28, 2019 at 9:11 PM Satish Duggana
> > wrote:
> >
>
sts are tracked?
>
> Thanks,
> Dhruvil
>
> On Mon, Oct 28, 2019 at 9:43 PM Satish Duggana
> wrote:
>
> > Hi All,
> > I wrote a short KIP about avoiding out-of-sync or offline partitions
> > when follower fetch requests are not processed in time by the leader
>
that they are identical copies.
>
> Jun
>
>
> On Fri, Nov 1, 2019 at 4:26 AM Satish Duggana
> wrote:
>
> > Hi Jun,
> > Thanks for looking into the updated KIP and clarifying our earlier queries.
> >
> > >20. It's fine to keep the HDFS binding
> Thanks,
>
> Jun
>
> On Mon, Oct 28, 2019 at 9:11 PM Satish Duggana
> wrote:
>
> > Hi Viktor,
> > >1. Can we allow RLM Followers to serve read requests? After all segments
> > on
> > the cold storage are closed ones, no modification is allowed. Besi
Hi All,
I wrote a short KIP about avoiding out-of-sync or offline partitions
when follower fetch requests are not processed in time by the leader
replica.
KIP-501 is located at https://s.apache.org/jhbpn
Please take a look, I would like to hear your feedback and suggestions.
JIRA:
> >> > It's probably worth it making it clearer in the KIP what exact
> >> > libraries will be added to libs, if any. The KIP specifies the remote
> >> > storage interface but it isn't clear if particular implementations
> >> > will be added to Ka
gt; > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Apr 1, 2019, at 1:02 AM, Viktor Somogyi-Vass wrote:
> > > > > > > > > Hey Harsha,
> > > > > > > > >
> > &g
reside in
> > > other repositories. If I understand the intention correctly, you are
> > > proposing to have an HDFS and S3 implementation as part of the Kafka
> > > repository working out of the box. Is that correct?
> > >
> > > Thanks
> > > Eno
>
repositories. If I understand the intention correctly, you are
> > proposing to have an HDFS and S3 implementation as part of the Kafka
> > repository working out of the box. Is that correct?
> >
> > Thanks
> > Eno
> >
> > On Wed, Oct 23, 2019 at 5:01 AM Satish
; > > > > the project so that it could be built and released separately
> > > from
> > > > > > the
> > > > > > > > main
> > > > > > > > > Kafka packages."
>
Thanks Jason for the KIP.
+1 (non-binding).
I assume this change will be added to the upgrade notes as the new
values are effective for clusters that were using earlier defaults.
Cluster may get into the race condition of having lower
replica.lag.time.max.ms on a leader than
g
> > > > for
> > > > > > > > other storage implementations.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Viktor
> > > > > > > >
> > > > > > >
Thanks Jason for the KIP. It looks to be a minor improvement but very useful.
+1 (non-binding)
On Wed, Sep 25, 2019 at 9:29 PM Rajini Sivaram wrote:
>
> Thanks for the KIP, Jason!
>
> +1 (binding)
>
> Regards,
>
> Rajini
>
> On Wed, Sep 25, 2019 at 4:41 PM Colin McCabe wrote:
>
> > Looks good.
Thanks for the KIP, +1 (non binding)
This looks to be a useful API for admin tools. When we worked on an
admin tool for Kafka, we had to explicitly call the config API for
showing the configs for the newly created topic.
I have a minor-nit comment on `CreateResult` which seems to be a
slightly
Hi Kevin,
Thanks for adding useful metrics with the KIP.
On Wed, 18 Sep, 2019, 1:49 AM Kevin Lu, wrote:
> Hi Manikumar,
>
> Thanks for the support.
>
> Since we have added a couple additional metrics, I have renamed the KIP
> title to reflect the content better: KIP-517: Add consumer metrics
uld be
> > > > > preferred leader should be modified. The broker in the preferred
> > > > > leader
> > > > > blacklist should be moved to the end (lowest priority) when
> > > > > determining leadership.
> > > > >
> > > >
+1 (non-binding) Thanks for the nice KIP.
You may want to update the KIP saying that optional tagged fields do
not support complex types(or structs).
On Wed, Sep 4, 2019 at 3:43 AM Jose Armando Garcia Sancio
wrote:
>
> +1 (non-binding)
>
> Looking forward to this improvement.
>
> On Tue, Sep 3,
Hi David,
Thanks for the KIP. I have a couple of questions.
>> For the Java client, the idea is to define two constants in the code to
>> store its name and its version. If possible, the version will be set
>> automatically based on metadata coming from gradle (or the repo itself) to
>> avoid
201 - 300 of 384 matches
Mail list logo
