respective event.
> >
> >
> > 5114.5 SegmentSizeInBytes: Could this just be int32?
> >
> > Right, it looks like config allows only int value >= 14.
> >
> > 5115. RemoteLogCleaner(RLC): This could be confused with the log cleaner
> > for compaction. Perh
[
https://issues.apache.org/jira/browse/KAFKA-10723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10723.
-
Fix Version/s: 2.8.0
Resolution: Fixed
merged to trunk
> LogManager leaks internal thread p
Hi, David,
Thanks for your interest. Just gave you the wiki permissions.
Jun
On Fri, Nov 6, 2020 at 11:03 AM David Mao wrote:
> Hi all,
>
> I'd like to make an update to a KIP, can I get edit permissions for
> Confluence?
>
> Thanks,
> David
>
[
https://issues.apache.org/jira/browse/KAFKA-10624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10624.
-
Fix Version/s: 2.8.0
Resolution: Fixed
merged the PR to trunk.
> [Easy] FeatureZNodeSta
Hi, Joshua,
Thanks for your interest. Just gave you the wiki permissions.
Jun
On Thu, Nov 5, 2020 at 10:02 AM Joshua Grisham
wrote:
> Hello!
>
> I was sent here from
>
> https://issues.apache.org/jira/browse/KAFKA-10640?focusedCommentId=17225581&page=com.atlassian.jira.plugin.system.issuetabpa
t; > > >
> > > > > > 604. "RLM maintains a bounded cache(possibly LRU) of the index
> > files of
> > > > > > remote log segments to avoid multiple index fetches from the
> remote
> > > > > > storage. These indexes can be used
Hi, Colin,
Thanks for the reply. A few more comments.
55. There is still text that favors new broker registration. "When a broker
first starts up, when it is in the INITIAL state, it will always "win"
broker ID conflicts. However, once it is granted a lease, it transitions
out of the INITIAL sta
[
https://issues.apache.org/jira/browse/KAFKA-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10599.
-
Fix Version/s: 2.7.0
Resolution: Fixed
Merged the PR to 2.7 and trunk.
> Implement basic
nce/display/KAFKA/KIP-584%3A+Versioning+scheme+for+features#KIP584:Versioningschemeforfeatures-Featureversiondeprecation
> > .
> >
> > Thank you for the suggestion.
> >
> >
> > Cheers,
> > Kowshik
> >
> >
> > On Tue, Oct 6, 2020 at 5:30 PM Jun Rao
Hi, Justine,
Thanks for the updated KIP. +1 from me.
Jun
On Tue, Oct 13, 2020 at 2:38 PM Jun Rao wrote:
> Hi, Justine,
>
> Thanks for starting the vote. Just a few minor comments.
>
> 1. It seems that we should remove the topic field from the
> StopReplicaResponse be
ks,
Jun
On Mon, Oct 12, 2020 at 11:14 AM Colin McCabe wrote:
> On Tue, Oct 6, 2020, at 16:09, Jun Rao wrote:
> > Hi, Colin,
> >
> > Thanks for the reply. Made another pass of the KIP. A few more comments
> > below.
> >
>
> Hi Jun,
>
> Thanks for the r
Hi, Justine,
Thanks for starting the vote. Just a few minor comments.
1. It seems that we should remove the topic field from the
StopReplicaResponse below?
StopReplica Response (Version: 4) => error_code [topics]
error_code => INT16
topics => topic topic_id* [partitions]
2. "After controll
[
https://issues.apache.org/jira/browse/KAFKA-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-9393.
Fix Version/s: 2.7.0
Assignee: Gardner Vickers
Resolution: Fixed
merged to trunk
Jun Rao created KAFKA-10584:
---
Summary: IndexSearchType should use sealed trait instead of
Enumeration
Key: KAFKA-10584
URL: https://issues.apache.org/jira/browse/KAFKA-10584
Project: Kafka
Issue
[
https://issues.apache.org/jira/browse/KAFKA-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10028.
-
Fix Version/s: 2.7.0
Resolution: Fixed
merged the PR to trunk
> Implement write path
eme+for+features#KIP584:Versioningschemeforfeatures-Featureversiondeprecation
> .
>
> Please let me know if you have any questions.
>
>
> Cheers,
> Kowshik
>
>
> On Tue, Sep 29, 2020 at 11:07 AM Jun Rao wrote:
>
> > Hi, Kowshik,
> >
> > Thanks fo
MetadataOffset since it's more
consistent with fetchOffset and HWM?
Thanks,
Jun
On Mon, Oct 5, 2020 at 9:03 AM Colin McCabe wrote:
> On Mon, Sep 28, 2020, at 11:41, Jun Rao wrote:
> > Hi, Colin,
> >
> > Thanks for the reply. A few more comments below.
> >
>
Hi, Jose,
Thanks for the KIP. +1. A couple of minor comments below.
1. The new configuration names suggested by Ron sound reasonable.
2. It seems that OFFSET_OUT_OF_RANGE in the wiki needs to be changed to
POSITION_OUT_OF_RANGE.
Jun
On Mon, Oct 5, 2020 at 9:46 AM Jason Gustafson wrote:
> +1 T
Hi, Javier,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Sat, Oct 3, 2020 at 8:59 AM Javier Freire Riobo
wrote:
> Hi,
>
> My UID is javier.freire. I wanted to create a KIP to add to Kafka Streams
> the ability to convert a changelog stream to a stream by computing the
>
Hi, Jose,
Thanks for the updated KIP. Just a couple of minor comments.
41. Perhaps metadata.snapshot.min.records.size can just
be metadata.snapshot.min.records?
42. It's probably fine to change maxBytes for Fetch in a separate PR. I
brought this up since this KIP is changing the Fetch request.
derstand that due to json, this field is written as a string, so if I
> should move the "option[uuid]" to the doc field and the type should be
> "string" please let me know.
>
> 40. I've added a definition for UUID.
> 41,42. Fixed
>
> Thank you,
> Justi
Hi, Jose,
Thanks for the reply. A few more comments.
41. That's a good point. With compacted topic, the cleaning won't be done
until the active segment rolls. With snapshots, I guess we don't have this
restriction? So, it would be useful to guard against too frequent
snapshotting. Does the new pr
t; > > deletion and I believe that is why the produce request was
> listed
> >> > under
> >> > > > > future work.
> >> > > > >
> >> > > > > 4. This sounds like it might be a good solution, but I will need
>
Hi, Jose,
Thanks for the updated KIP. A few more comments below.
40. LBO: Code wise, logStartOffset is used in so many places like Log,
ReplicaManager, LogCleaner, ReplicaFetcher, checkpoint files, etc. I am not
if it's worth renaming in all those places. If the main concern is to
avoid confusion
t; becomes useful. Using this, a client
> could
> >> > >>> learn the
> >> > >>> > > > specific supported versions that's lower than
> >> max_version_level
> >> > >>> (instead
> >> > >>> > > of
>
Jun
On Mon, Sep 28, 2020 at 9:24 AM Colin McCabe wrote:
> On Fri, Sep 25, 2020, at 17:35, Jun Rao wrote:
> > Hi, Colin,
> >
> > Thanks for the reply.
> >
> > 62. Thinking about this more, I am wondering what's our overall strategy
> > for configs s
ed, it seems that it's less confusing to make
> > controller.id required.
> > (b) I am still trying to understand if we truly need to expose a
> > controller.id. What if we only expose broker.id and let
> controller.connect
> > just use broker.id? What w
Hi, Jose,
Thanks for the reply. A few more comments below.
20. Good point on metadata cache. I think we need to make a decision
consistently. For example, if we decide that dedicated voter nodes don't
serve metadata requests, then we don't need to expose the voters host/port
to the client. Which
t; other
> >>> > > > > words, increasing minVersionLevel on the broker) is an
> >>> incompatible
> >>> > > change,
> >>> > > > > which requires a major release of Kafka.
> >>> > &g
at best effort. Additionally, we are not
> proposing any incompatible changes such as principal serialization. We
> shall still use the split and join semantic we built as of current to only
> forward authenticated resources.
>
> Let me know if this makes sense.
>
> Boyang
>
> On
On Thu, Sep 24, 2020 at 10:55 PM Colin McCabe wrote:
> On Thu, Sep 24, 2020, at 16:24, Jun Rao wrote:
> > Hi, Colin,
> >
> > Thanks for the reply and the updated KIP. A few more comments below.
> >
>
> Hi Jun,
>
> >
> > 53. It seems that you alre
a cross-broker dependence. However,
> KIP-584 would still allow us to manage the IBP at the level of a feature so
> that we don't need two rolling restarts anymore.
>
> Best,
> Jason
>
>
>
>
> On Thu, Sep 24, 2020 at 1:59 PM Jun Rao wrote:
>
> > Hi,
the metadata can be
removed. Since the Fetch response returns the HWM, there seems to be enough
APIs to achieve this.
Jun
On Thu, Sep 24, 2020 at 1:07 PM Colin McCabe wrote:
> On Mon, Sep 21, 2020, at 18:13, Jun Rao wrote:
> > Hi, Colin,
> >
> > Sorry for the late reply.
Hi, Boyang,
One of the goals of KIP-584 (feature versioning) is that we can get rid of
IBP in the future. So does this change prevent us from removing IBP in the
future?
Thanks,
Jun
On Thu, Sep 24, 2020 at 12:46 PM Jason Gustafson wrote:
> Hey Boyang,
>
> Thanks for the update. This seems lik
> > > Hi Tom,
> >> > > >
> >> > > > Thanks for the comment. I think this is a really good idea and it
> >> has
> >> > > been
> >> > > > added to the KIP under the newly added tooling section.
> >> >
> > >
> > > Please let me know if there is anything else we should discuss before
> > > voting.
> > >
> > > Thank you,
> > > Justine
> > >
> > > On Fri, Sep 18, 2020 at 9:46 AM Justine Olshan
> > > wrote:
> > >
nd epoch. I think we should
> just leave it empty in this case. The snapshot offset and epoch seem
> sufficient.
>
>
> Thanks,
> Jason
>
> On Fri, Aug 7, 2020 at 11:33 AM Jose Garcia Sancio
> wrote:
>
> > Thanks for your feedback Jun.
> >
> > H
Hi, Colin,
Sorry for the late reply. A few more comments below.
50. Configurations
50.1 controller.listeners: It seems that a controller just needs one
listener. Why do we need to have a list here? Also, could you provide an
example of how this is set and what's its relationship with existing
con
not
> really sure what happens in kafka when the log directory is renamed
> manually in such a way. I'm also wondering if the situation is recoverable
> in this scenario.
>
> Thanks,
> Justine
>
> On Thu, Sep 17, 2020 at 4:28 PM Jun Rao wrote:
>
> > Hi, Justine,
e has
> been deleted. In that case, we would need to delete the old topic and start
> receiving the new version. If the topic name were to change, but the ids
> still matched, the file would also need to update. Am I missing a case
> where the file would be correct and not the re
e:
> >
> >> Hi all,
> >> Jun brought up a good point in his last email about tagged fields, and
> >> I've updated the KIP to reflect that the changes to requests and
> responses
> >> will be in the form of tagged fields to avoid changing IBP.
>
Hi, Justine,
Thanks for the updated KIP. A few comments below.
10. LeaderAndIsr Response: Do we need the topic name?
11. For the changed request/response, other than LeaderAndIsr,
UpdateMetadata, Metadata, do we need to include the topic name?
12. It seems that upgrades don't require IBP. Does
goals" section.
>
> Thanks,
> Satish.
>
> On Thu, Aug 27, 2020 at 12:42 AM Harsha Ch wrote:
> >
> > Updated the KIP with Meeting Notes section
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage#KIP405:KafkaTieredStorage-Meetin
Hi, Sorin,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Sat, Aug 29, 2020 at 8:35 AM sorin
wrote:
> Hi guys I just wanted to propose an addition to the Consumer API to add
> a new poll method which would also accept a collection of paused
> partitions to automatically do
Hi, Rupesh,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Fri, Aug 28, 2020 at 8:09 AM rupesh patel
wrote:
> Hi Team,
>
> Please provide me permission to create a KIP
>
> My Wiki id: rupeshkumarpatel02
>
>
> Thanks,
> Rupesh Kumar Patel
>
Hi, Brandon,
Thanks for your interest. Just gave you the wiki permission.
Jun
On Thu, Aug 27, 2020 at 1:17 PM Brandon Brown
wrote:
> I’d like to request permission to create a KIP. My username is brbrown35.
>
> Thanks,
> Brandon
>
> Brandon Brown
> (240) 506-8335 (m)
Hi, Mandeep,
Thanks for your interest. Just gave you the wiki permissions.
Jun
On Wed, Aug 26, 2020 at 9:08 PM mandeep gandhi
wrote:
> Hi all,
>
> Please grant me access to create a KIP.
>
> Email - welcomemand...@gmail.com
> Username - ifconfig
>
> Thanks,
> Mandeep Gandhi
>
Hi, Aakash,
Thanks for your interest. Just gave you the wiki permissions.
Jun
On Wed, Aug 26, 2020 at 11:57 AM Aakash Gupta
wrote:
> Hi,
>
> Please grant me the access to create wiki page to submit KIP proposal.
>
> Full Name: Aakash Gupta
> Email ID: aakash.gupt...@outlook.com
>
> Regards,
>
he discussion.
> >
> > Jun, please add the required folks on confluent side.
> >
> > Thanks,
> >
> > Harsha
> >
> > On Thu, Aug 20, 2020 at 12:33 AM, Alexandre Dupriez < alexandre.dupriez@
> > gmail.com > wrote:
> >
> > Hi J
Hi, Ben,
Thanks for your interest. Added you.
Jun
On Mon, Aug 24, 2020 at 3:27 AM Ben Stopford wrote:
> Please add me too.
>
> On Fri, 21 Aug 2020 at 16:08, Jun Rao wrote:
>
> > Hi, Bill,
> >
> > Thanks for your interest. Added you.
> >
> > Jun
&g
Hi, Bill,
Thanks for your interest. Added you.
Jun
On Fri, Aug 21, 2020 at 7:42 AM Bill Bejeck wrote:
> Hi Jun,
>
> I'd like to attend as well.
>
> Thanks,
> Bill
>
> On Fri, Aug 21, 2020 at 10:27 AM Jun Rao wrote:
>
> > Hi, Adam,,
> >
> >
Hi, Adam,,
Thanks for your interest. Invited you.
Jun
On Thu, Aug 20, 2020 at 5:03 PM Adam Bellemare
wrote:
> Hello
>
> I am interested in attending, mostly just to listen and observe.
>
> Thanks !
>
> > On Aug 20, 2020, at 6:20 PM, Jun Rao wrote:
> >
> &g
Hi, everyone,
We plan to have weekly virtual meetings for KIP-405 to discuss progress and
outstanding issues, starting from this coming Tuesday at 9am PT. If you are
interested in attending, please let Harsha or me know.
The recording of the meeting will be posted in
https://cwiki.apache.org/conf
rmance 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/cons of making the RSM apis asynchronous?
> >
> >
> > Cheers,
> > Kowshik
> >
> >
> > O
Hi, Everyone,
John Roesler has been a Kafka committer since Nov. 5, 2019. He has remained
active in the community since becoming a committer. It's my pleasure to
announce that John is now a member of Kafka PMC.
Congratulations John!
Jun
on behalf of Apache Kafka PMC
Hi, Jason,
Thanks for the KIP. +1
Just to confirm. For those newly added request types, will we expose the
existing latency metrics (total, local, remote, etc) with a new tag
request=[request-type]?
Jun
On Tue, Aug 4, 2020 at 3:00 PM Boyang Chen
wrote:
> Thanks for the KIP Jason, +1 (binding)
Hi, Jose,
Thanks for the KIP. A few comments blow.
10. I agree with Jason that it's useful to document the motivation a bit
clearer. Regarding semantic/performance, one benefit of snapshotting is
that it allows changes to be encoded incrementally instead of using the
full post image. For example,
>> dis-connection?
> > > >>
> > > >>
> > > >> > As discussed in the Raft Thesis section 6.4, the linearizable
> > > semantics
> > > >> of
> > > >> > read requests is implemented
age as the source-of-truth, the follower logic can be a
> little simpler,
> but the leader logic is going to be more complex. Overall, I don't see
> there many benefits
> of using remote storage as the source-of-truth.
>
>
>
> On Tue, Jul 28, 2020 at 10:25 AM Jun Rao
Hi, Everyone,
Mickael Maison has been a Kafka committer since Nov. 5, 2019. He has
remained active in the community since becoming a committer. It's my
pleasure to announce that Mickael is now a member of Kafka PMC.
Congratulations Mickael!
Jun
on behalf of Apache Kafka PMC
t; convention, we need to introduce local.log.retention instead of
> remote.log.retention.ms that we proposed. If log.retention.ms as -1
> then remote retention is also considered as unlimited but user should
> be able to set the local.retention.ms.
> So, we need to introduce local.log.r
Hi, Colin,
Thanks for the KIP. A few comments below.
10. Some of the choices in this KIP are not consistent with KIP-595. It
would be useful to make consistent choices between the two KIPs.
10.1 KIP-595 doesn't use a separate Heartbeat request and heartbeat is
piggybacked through the Fetch reques
ink it is generally safe to start from an empty
> state.
>
> 206. Yes, that is discussed in KIP-631 I believe.
>
> 207. Good suggestion. I will work on this.
>
>
> Thanks,
> Jason
>
>
>
>
>
> On Thu, Jul 16, 2020 at 3:44 PM Jun Rao wrote:
>
> > Hi
[
https://issues.apache.org/jira/browse/KAFKA-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10300.
-
Fix Version/s: 2.7.0
Resolution: Fixed
merged to trunk
> fix flaky c
all limitations in a separate section:
> compacted topic, JBOD, etc. Also, is changing a topic from delete to
> compact and vice versa allowed when tiering is enabled?
>
> +1 to have limitations in a separate section. We will update the KIP with
> that.
> Topic created wit
[
https://issues.apache.org/jira/browse/KAFKA-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10274.
-
Fix Version/s: 2.6.0
Resolution: Fixed
Merged this to trunk and 2.6 branch.
> Transact
> I agree with Colin that the current design of using rocksDB is not
> > > optimal. But this design is simple and should work for almost all the
> > > existing Kafka users. RLMM is a plugin. Users can replace rocksDB with
> > > their own RLMM implementation, if needed. So, I
> will plan to start a vote later this week.
>
> Thanks,
> Jason
>
> On Wed, Jun 24, 2020 at 10:43 AM Guozhang Wang wrote:
>
> > @Jun Rao
> >
> > Regarding your comment about log compaction. After some deep-diving into
> > this we've decided t
[
https://issues.apache.org/jira/browse/KAFKA-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10257.
-
Fix Version/s: 2.6.0
Resolution: Fixed
Merged to 2.6 and trunk.
> system t
[
https://issues.apache.org/jira/browse/KAFKA-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10002.
-
Fix Version/s: 2.7.0
Resolution: Fixed
merged the PR to trunk
> Improve performances
[
https://issues.apache.org/jira/browse/KAFKA-10235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10235.
-
Fix Version/s: 3.0.0
Resolution: Fixed
merged the PR to trunk.
> Fix flaky transactions_test
Jun Rao created KAFKA-10257:
---
Summary: system test
kafkatest.tests.core.security_rolling_upgrade_test fails
Key: KAFKA-10257
URL: https://issues.apache.org/jira/browse/KAFKA-10257
Project: Kafka
[
https://issues.apache.org/jira/browse/KAFKA-10225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10225.
-
Fix Version/s: 2.7.0
Resolution: Fixed
merged the PR to trunk
> Increase default zk sess
the recent design changes (e.g. leader epoch info
> management / log truncation / some of the new metrics) have not been
> implemented yet. It will take about 2 weeks for us to implement after you
> review and agree with those design changes.
>
>
>
> On Tue, Jul 7, 2020 at 9:23 AM Ju
>
> > > > We will cover this in the KIP.
> > > >
> > > > >112. Truncation of remote segments under unclean leader election: I
> am not sure who figures out the truncated remote segments and how that
> information is propagated to all replicas?
> > > &g
[
https://issues.apache.org/jira/browse/KAFKA-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-9769.
Fix Version/s: 2.7.0
Assignee: Andrew Choi
Resolution: Fixed
merged the PR to trunk
gt; the existing one once it is added to the accepted dynamic configs for the
> > user
> > and the client entities. I have added a "Kafka Config Command" chapter in
> > the
> > KIP. I will also open a Jira to not forget updating the AK documentation
> > once
>
[
https://issues.apache.org/jira/browse/KAFKA-10027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10027.
-
Fix Version/s: 2.7.0
Assignee: Kowshik Prakasam
Resolution: Fixed
merged the PR to
/metrics/core/Meter.html
).
Jun
On Wed, Jun 10, 2020 at 10:38 AM Boyang Chen
wrote:
> Thanks Jun for the suggestions! I have addressed suggestion and simplified
> the metrics part.
>
> On Tue, Jun 9, 2020 at 5:46 PM Jun Rao wrote:
>
> > Hi, Boyang,
> >
> > Thanks fo
uld distinguish the two cases by
> the error string. But typically we want error strings to be used to give
> extra debugging information, not to make big decisions about what the
> client should do. So I think that the error code should actually be a
> little bit more speci
Hi, Boyang,
Thanks for the KIP. Just a few comments on the metrics.
1. It would be useful to document the full JMX metric names (package, type,
etc) of the new metrics. Also, for rates on the server side, we
typically use Yammer Meter.
2. For num-messages-redirected-rate, would num-requests-redi
gt; quota.
>
> Best,
> David
>
> On Tue, Jun 9, 2020 at 7:48 PM Jun Rao wrote:
>
> > Hi, David,
> >
> > Another thing. Should we add controller.quota.window.size.seconds and
> > controller.quota.window.num
> > or just reuse the existing quota.window.s
Hi, David,
Another thing. Should we add controller.quota.window.size.seconds and
controller.quota.window.num
or just reuse the existing quota.window.size.seconds and quota.window.num
that are used for other types of quotas?
Thanks,
Jun
On Tue, Jun 9, 2020 at 10:30 AM Jun Rao wrote:
>
nd another name. QUOTA_EXHAUSTED? I don't feel too strongly about
> the naming. I wonder what the others think about this.
>
> Voilà. I hope that I have addressed all your questions/points and I am
> sorry for
> the lengthy email.
>
> Regards,
> David
>
>
> On Tue, J
t wait. This is explained
> in the
> "Handling of new/old clients".
>
> Best,
> David
>
> On Mon, Jun 8, 2020 at 9:29 PM Jun Rao wrote:
>
> > Hi, David,
> >
> > Thanks for the updated KIP. Another minor comment below.
> >
> > 40. For the
Hi, Colin,
Thanks for the comment. You brought up several points.
1. Should we set up a per user quota? To me, it does seem we need some sort
of a quota. When the controller runs out of resources, ideally, we only
want to penalize the bad behaving applications, instead of every
application. To do
am going to the voting thread...
> >
> > Hi Jun,
> >
> > Yes, exactly. That's a separate thing from this KIP, so working on the
> fix.
> >
> > Thanks,
> > Anna
> >
> > On Fri, Jun 5, 2020 at 4:36 PM Jun Rao wrote:
> >
> >
[
https://issues.apache.org/jira/browse/KAFKA-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-10106.
-
Fix Version/s: 2.7.0
Assignee: NIKHIL
Resolution: Fixed
Merged the PR to trunk.
>
orithm "So instead of having one sample equal to 560 in the
> last
> > window, we will have 100 samples equal to 5.6.", I agree with Jun. I
> would
> > allocate 5 per each old sample that is still in the overall window. It
> > would be a bit larger granularity than t
So, we could keep "window size" and
> > > "number
> > > >> of samples" configs and change Rate implementation to be more
> similar
> > to
> > > >> token bucket:
> > > >> * number of samples define our burst size
> &g
Jun Rao created KAFKA-10101:
---
Summary: recovery point is advanced without flushing the data
after recovery
Key: KAFKA-10101
URL: https://issues.apache.org/jira/browse/KAFKA-10101
Project: Kafka
%, 0 meaning that the user is throttled;
> It remains disattach from the algorithm.
>
> I personally prefer this over having to define a rate and a number of
> windows
> while having to understand that the number of windows implicitly defines
> the
> allowed burst. I t
Hi, David, Anna,
Thanks for the response. Sorry for the late reply.
10. Regarding exposing rate or usage as quota. Your argument is that usage
is not very accurate anyway and is harder to implement. So, let's just be a
bit loose and expose rate. I am sort of neutral on that. (1) It seems to me
th
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 with wiki.
>>
>> Thanks,
>> Satish.
>>
>> On Tue, May 19, 2020 at 12:30 AM Jun
s KIP.
>
> We added a few tests by introducing test util for tiered storage in the
> PR. We will provide the testing plan in the next few days.
>
> Thanks,
> Satish.
>
>
> On Wed, Feb 26, 2020 at 9:43 PM Harsha Chintalapani
> wrote:
>
>>
>>
>>
>>
, May 4, 2020 at 11:58 AM Jun Rao wrote:
>
> > Hi, Guozhang,
> >
> > Thanks for the reply. A few more replies inlined below.
> >
> > On Sun, May 3, 2020 at 6:33 PM Guozhang Wang wrote:
> >
> > > Hello Jun,
> > >
> > > Thanks for your
Hi, Guozhang,
Thanks for the reply. A few more replies inlined below.
On Sun, May 3, 2020 at 6:33 PM Guozhang Wang wrote:
> Hello Jun,
>
> Thanks for your comments! I'm replying inline below:
>
> On Fri, May 1, 2020 at 12:36 PM Jun Rao wrote:
>
> > 101. Bootstrapp
Hi, Jason,
Thanks for the KIP. Great writeup. A few comments below.
100. Do we need AlterQuorum in the first version? Quorum changes are rare
and the implementation is involved. ZK doesn't have that until 4 years
after the initial version. Dropping that in the first version could speed
up this KI
5, 2020 at 4:52 PM Jun Rao wrote:
> Hi, Everyone,
>
> Here is an update on the upcoming Kafka Summit events in 2020.
>
> 1. Unfortunately, Kafka Summit London, originally planned on Apr 27/28,
> has been cancelled due to COVID-19.
>
> 2. Kafka Summit Austin (Aug 24/
g one request with multiple topics.
> The
> reasoning behind allowing a burst is to allow such requests with a
> reasonable
> size to pass without being throttled whereas our current quota mechanism
> would reject any topics as soon as the rate is above the quota requiring
> the
&
401 - 500 of 5842 matches
Mail list logo
