[jira] [Commented] (KAFKA-10101) recovery point is advanced without flushing the data after recovery

[ https://issues.apache.org/jira/browse/KAFKA-10101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126023#comment-17126023 ] Jun Rao commented on KAFKA-10101: - [~ijuma] : Could you double check if this is an issue? Thanks. >

[jira] [Created] (KAFKA-10101) recovery point is advanced without flushing the data after recovery

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

[jira] [Commented] (KAFKA-806) Index may not always observe log.index.interval.bytes

[ https://issues.apache.org/jira/browse/KAFKA-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118904#comment-17118904 ] Jun Rao commented on KAFKA-806: --- [~mjsax]: I think this is still an issue. > Index may not always observe

[jira] [Commented] (KAFKA-9826) Log cleaning repeatedly picks same segment with no effect when first dirty offset is past start of active segment

[ https://issues.apache.org/jira/browse/KAFKA-9826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101751#comment-17101751 ] Jun Rao commented on KAFKA-9826: [~fekelund]: Yes. Updated the fix versions. > Log cleaning repeatedly

[jira] [Updated] (KAFKA-9826) Log cleaning repeatedly picks same segment with no effect when first dirty offset is past start of active segment

[ https://issues.apache.org/jira/browse/KAFKA-9826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-9826: --- Fix Version/s: 2.5.1 2.4.2 > Log cleaning repeatedly picks same segment with no effect

[jira] [Resolved] (KAFKA-9866) Do not attempt to elect preferred leader replicas which are outside ISR

[ https://issues.apache.org/jira/browse/KAFKA-9866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-9866. Fix Version/s: 2.6.0 Resolution: Fixed Merged the PR to trunk. > Do not attempt to elect preferred

[jira] [Commented] (KAFKA-2419) Allow certain Sensors to be garbage collected after inactivity

[ https://issues.apache.org/jira/browse/KAFKA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090711#comment-17090711 ] Jun Rao commented on KAFKA-2419: Sensor expiring is only used on the broker. For the clients, typically

[jira] [Created] (KAFKA-9892) Producer state snapshot needs to be forced to disk

Jun Rao created KAFKA-9892: -- Summary: Producer state snapshot needs to be forced to disk Key: KAFKA-9892 URL: https://issues.apache.org/jira/browse/KAFKA-9892 Project: Kafka Issue Type: Bug

[jira] [Commented] (KAFKA-9543) Consumer offset reset after new segment rolling

[ https://issues.apache.org/jira/browse/KAFKA-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17085916#comment-17085916 ] Jun Rao commented on KAFKA-9543: [~hachikuji]: Thanks for the analysis. It does seem this issue could be

[jira] [Resolved] (KAFKA-8470) State change logs should not be in TRACE level

[ https://issues.apache.org/jira/browse/KAFKA-8470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-8470. Fix Version/s: 2.6.0 Resolution: Fixed Merged the PR to trunk.     1. Defaults state-change log

[jira] [Resolved] (KAFKA-9711) The authentication failure caused by SSLEngine#beginHandshake is not properly caught and handled

[ https://issues.apache.org/jira/browse/KAFKA-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-9711. Fix Version/s: 2.6.0 Resolution: Fixed Merged the PR to trunk. > The authentication failure caused

[jira] [Commented] (KAFKA-3919) Broker faills to start after ungraceful shutdown due to non-monotonically incrementing offsets in logs

[ https://issues.apache.org/jira/browse/KAFKA-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17061243#comment-17061243 ] Jun Rao commented on KAFKA-3919: [~zhangchenghui]: Appreciate the detailed analysis. I noticed that the

[jira] [Commented] (KAFKA-9693) Kafka latency spikes caused by log segment flush on roll

[ https://issues.apache.org/jira/browse/KAFKA-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17057325#comment-17057325 ] Jun Rao commented on KAFKA-9693: [~paolomoriello]: By metadata, I was referring to the metadata in the

[jira] [Commented] (KAFKA-9693) Kafka latency spikes caused by log segment flush on roll

[ https://issues.apache.org/jira/browse/KAFKA-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17057256#comment-17057256 ] Jun Rao commented on KAFKA-9693: [~paolomoriello]: Thanks for the reply. Do you know if the increase

[jira] [Commented] (KAFKA-9693) Kafka latency spikes caused by log segment flush on roll

[ https://issues.apache.org/jira/browse/KAFKA-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056188#comment-17056188 ] Jun Rao commented on KAFKA-9693: [~paolomoriello]: Thanks for the detailed analysis. Very interesting.

[jira] [Commented] (KAFKA-9677) Low consume bandwidth quota may cause consumer not being able to fetch data

[ https://issues.apache.org/jira/browse/KAFKA-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053839#comment-17053839 ] Jun Rao commented on KAFKA-9677: [~apovzner] : Thanks for finding this issue! I agree with your suggested

[jira] [Commented] (KAFKA-9648) kafka server should resize backlog when create serversocket

[ https://issues.apache.org/jira/browse/KAFKA-9648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052419#comment-17052419 ] Jun Rao commented on KAFKA-9648: [~flashmouse] : Thanks for the reply. Just to clarify. TCP window

[jira] [Commented] (KAFKA-9648) kafka server should resize backlog when create serversocket

[ https://issues.apache.org/jira/browse/KAFKA-9648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051699#comment-17051699 ] Jun Rao commented on KAFKA-9648: [~flashmouse]: Thanks for the analysis. Great finding! The impact seems

[jira] [Resolved] (KAFKA-9498) Topic validation during the creation trigger unnecessary TopicChange events

[ https://issues.apache.org/jira/browse/KAFKA-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-9498. Fix Version/s: 2.6.0 Resolution: Fixed Merged the PR to trunk. > Topic validation during the

[jira] [Commented] (KAFKA-4084) automated leader rebalance causes replication downtime for clusters with too many partitions

[ https://issues.apache.org/jira/browse/KAFKA-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042307#comment-17042307 ] Jun Rao commented on KAFKA-4084: https://issues.apache.org/jira/browse/KAFKA-9594 identifies an issue

[jira] [Resolved] (KAFKA-6266) Kafka 1.0.0 : Repeated occurrence of WARN Resetting first dirty offset of __consumer_offsets-xx to log start offset 203569 since the checkpointed offset 120955 is invali

[ https://issues.apache.org/jira/browse/KAFKA-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-6266. Resolution: Fixed Merged into 2.4 and trunk. > Kafka 1.0.0 : Repeated occurrence of WARN Resetting first

[jira] [Commented] (KAFKA-6266) Kafka 1.0.0 : Repeated occurrence of WARN Resetting first dirty offset of __consumer_offsets-xx to log start offset 203569 since the checkpointed offset 120955 is inval

[ https://issues.apache.org/jira/browse/KAFKA-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039522#comment-17039522 ] Jun Rao commented on KAFKA-6266: [~david.mao]: I merged the PR to trunk. However, it doesn't apply to

[jira] [Commented] (KAFKA-7061) Enhanced log compaction

[ https://issues.apache.org/jira/browse/KAFKA-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034592#comment-17034592 ] Jun Rao commented on KAFKA-7061: [~senthilm-ms] : Sorry for the delay. I will review the PR this week. >

[jira] [Commented] (KAFKA-8374) KafkaApis.handleLeaderAndIsrRequest not robust to ZooKeeper exceptions

[ https://issues.apache.org/jira/browse/KAFKA-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033734#comment-17033734 ] Jun Rao commented on KAFKA-8374: This could be related to 

[jira] [Commented] (KAFKA-4084) automated leader rebalance causes replication downtime for clusters with too many partitions

[ https://issues.apache.org/jira/browse/KAFKA-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032006#comment-17032006 ] Jun Rao commented on KAFKA-4084: Do you see the incoming byte rate of that broker much more than

[jira] [Commented] (KAFKA-4084) automated leader rebalance causes replication downtime for clusters with too many partitions

[ https://issues.apache.org/jira/browse/KAFKA-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031955#comment-17031955 ] Jun Rao commented on KAFKA-4084: [~evanjpw]: There are metrics related to replication throttling

[jira] [Commented] (KAFKA-4084) automated leader rebalance causes replication downtime for clusters with too many partitions

[ https://issues.apache.org/jira/browse/KAFKA-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030864#comment-17030864 ] Jun Rao commented on KAFKA-4084: [~evanjpw]: I am not sure if you need the new config. The controller

[jira] [Commented] (KAFKA-4084) automated leader rebalance causes replication downtime for clusters with too many partitions

[ https://issues.apache.org/jira/browse/KAFKA-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030819#comment-17030819 ] Jun Rao commented on KAFKA-4084: [~evanjpw]: # For this case, you do have to script up things yourself.

[jira] [Commented] (KAFKA-4084) automated leader rebalance causes replication downtime for clusters with too many partitions

[ https://issues.apache.org/jira/browse/KAFKA-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030298#comment-17030298 ] Jun Rao commented on KAFKA-4084: [~sriharsha], hmm, if one sets follower.replication.throttled.rate to

[jira] [Commented] (KAFKA-8532) controller-event-thread deadlock with zk-session-expiry-handler0

[ https://issues.apache.org/jira/browse/KAFKA-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021795#comment-17021795 ] Jun Rao commented on KAFKA-8532: [~lbdai3190] :  To verify this, I wrote the following short program. I

[jira] [Commented] (KAFKA-8532) controller-event-thread deadlock with zk-session-expiry-handler0

[ https://issues.apache.org/jira/browse/KAFKA-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019835#comment-17019835 ] Jun Rao commented on KAFKA-8532: [~lbdai3190]: Thanks for the followup investigation. The following code

[jira] [Commented] (KAFKA-8532) controller-event-thread deadlock with zk-session-expiry-handler0

[ https://issues.apache.org/jira/browse/KAFKA-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018279#comment-17018279 ] Jun Rao commented on KAFKA-8532: [~lbdai3190]: Sorry for the late reply. Took a look at your last

[jira] [Commented] (KAFKA-8764) LogCleanerManager endless loop while compacting/cleaning segments

[ https://issues.apache.org/jira/browse/KAFKA-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013081#comment-17013081 ] Jun Rao commented on KAFKA-8764: [~trajakovic]: Thanks for providing the additional info. That makes

[jira] [Commented] (KAFKA-8764) LogCleanerManager endless loop while compacting/cleaning segments

[ https://issues.apache.org/jira/browse/KAFKA-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013058#comment-17013058 ] Jun Rao commented on KAFKA-8764: [~trajakovic]: Thanks for the investigation. Normally, the offset map is

[jira] [Commented] (KAFKA-6266) Kafka 1.0.0 : Repeated occurrence of WARN Resetting first dirty offset of __consumer_offsets-xx to log start offset 203569 since the checkpointed offset 120955 is inval

[ https://issues.apache.org/jira/browse/KAFKA-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987550#comment-16987550 ] Jun Rao commented on KAFKA-6266: Looking at the code where the "Resetting first dirty offset " warning is

[jira] [Commented] (KAFKA-9044) Brokers occasionally (randomly?) dropping out of clusters

[ https://issues.apache.org/jira/browse/KAFKA-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974548#comment-16974548 ] Jun Rao commented on KAFKA-9044: [~pmbuko]: Thanks for the update. > Brokers occasionally (randomly?)

[jira] [Commented] (KAFKA-9044) Brokers occasionally (randomly?) dropping out of clusters

[ https://issues.apache.org/jira/browse/KAFKA-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969452#comment-16969452 ] Jun Rao commented on KAFKA-9044: The ZK session is typically created when the broker starts, not when it

[jira] [Created] (KAFKA-9157) logcleaner could generate empty segment files after cleaning

Jun Rao created KAFKA-9157: -- Summary: logcleaner could generate empty segment files after cleaning Key: KAFKA-9157 URL: https://issues.apache.org/jira/browse/KAFKA-9157 Project: Kafka Issue Type:

[jira] [Commented] (KAFKA-9044) Brokers occasionally (randomly?) dropping out of clusters

[ https://issues.apache.org/jira/browse/KAFKA-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968926#comment-16968926 ] Jun Rao commented on KAFKA-9044: When a broker establishes a ZK session, it should log the session id as

[jira] [Commented] (KAFKA-9044) Brokers occasionally (randomly?) dropping out of clusters

[ https://issues.apache.org/jira/browse/KAFKA-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968861#comment-16968861 ] Jun Rao commented on KAFKA-9044: Hmm, I did a quick check and the controller seems to never delete a

[jira] [Commented] (KAFKA-9044) Brokers occasionally (randomly?) dropping out of clusters

[ https://issues.apache.org/jira/browse/KAFKA-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968833#comment-16968833 ] Jun Rao commented on KAFKA-9044: Interesting, that ZK session lasted for only 30 secs. This almost seems

[jira] [Commented] (KAFKA-9044) Brokers occasionally (randomly?) dropping out of clusters

[ https://issues.apache.org/jira/browse/KAFKA-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968793#comment-16968793 ] Jun Rao commented on KAFKA-9044: Did the ZK log show that broker 23's ZK session expired around that

[jira] [Commented] (KAFKA-9044) Brokers occasionally (randomly?) dropping out of clusters

[ https://issues.apache.org/jira/browse/KAFKA-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968545#comment-16968545 ] Jun Rao commented on KAFKA-9044: It may also be useful to parse the ZK commit log to see if there is any

[jira] [Commented] (KAFKA-7987) a broker's ZK session may die on transient auth failure

[ https://issues.apache.org/jira/browse/KAFKA-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967806#comment-16967806 ] Jun Rao commented on KAFKA-7987: [~gcampbell], we could try calling scheduleSessionExpiryHandler() in 

[jira] [Commented] (KAFKA-8522) Tombstones can survive forever

[ https://issues.apache.org/jira/browse/KAFKA-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919669#comment-16919669 ] Jun Rao commented on KAFKA-8522: [~Yohan123], not sure that I fully understood your question. We need to

[jira] [Commented] (KAFKA-8522) Tombstones can survive forever

[ https://issues.apache.org/jira/browse/KAFKA-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910793#comment-16910793 ] Jun Rao commented on KAFKA-8522: [~Yohan123], I was thinking the new checkpoint file will be under

[jira] [Commented] (KAFKA-8522) Tombstones can survive forever

[ https://issues.apache.org/jira/browse/KAFKA-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905792#comment-16905792 ] Jun Rao commented on KAFKA-8522: [~Yohan123]: For upgrade, we can roughly do the following. If the new

[jira] [Commented] (KAFKA-8522) Tombstones can survive forever

[ https://issues.apache.org/jira/browse/KAFKA-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902334#comment-16902334 ] Jun Rao commented on KAFKA-8522: [~Yohan123], I was thinking of adding a new checkpoint file per

[jira] [Commented] (KAFKA-8716) broker cannot join the cluster after upgrading kafka binary from 2.1.1 to 2.2.1 or 2.3.0

[ https://issues.apache.org/jira/browse/KAFKA-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902324#comment-16902324 ] Jun Rao commented on KAFKA-8716: [~yuyang08], thanks for the update. > broker cannot join the cluster

[jira] [Commented] (KAFKA-4545) tombstone needs to be removed after delete.retention.ms has passed after it has been cleaned

[ https://issues.apache.org/jira/browse/KAFKA-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899305#comment-16899305 ] Jun Rao commented on KAFKA-4545: [~Yohan123], if you want to work on this jira and follow the approach I

[jira] [Commented] (KAFKA-8716) broker cannot join the cluster after upgrading kafka binary from 2.1.1 to 2.2.1 or 2.3.0

[ https://issues.apache.org/jira/browse/KAFKA-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894142#comment-16894142 ] Jun Rao commented on KAFKA-8716: It's weird that the session was closed very quickly after SyncConnected.

[jira] [Commented] (KAFKA-8716) broker cannot join the cluster after upgrading kafka binary from 2.1.1 to 2.2.1 or 2.3.0

[ https://issues.apache.org/jira/browse/KAFKA-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893977#comment-16893977 ] Jun Rao commented on KAFKA-8716: Hmm, that's kind of weird. We do wait for the ZK session to be connected

[jira] [Commented] (KAFKA-8716) broker cannot join the cluster after upgrading kafka binary from 2.1.1 to 2.2.1 or 2.3.0

[ https://issues.apache.org/jira/browse/KAFKA-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893925#comment-16893925 ] Jun Rao commented on KAFKA-8716: Currently, we don't handle ZK session expiration for the initial broker

[jira] [Commented] (KAFKA-8522) Tombstones can survive forever

[ https://issues.apache.org/jira/browse/KAFKA-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893052#comment-16893052 ] Jun Rao commented on KAFKA-8522: [~Yohan123], this jira is similar to KAFKA-4545 and likely requires the

[jira] [Commented] (KAFKA-8522) Tombstones can survive forever

[ https://issues.apache.org/jira/browse/KAFKA-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878247#comment-16878247 ] Jun Rao commented on KAFKA-8522: Since we are returning the tombstone to the consumer, it may not be

[jira] [Commented] (KAFKA-8522) Tombstones can survive forever

[ https://issues.apache.org/jira/browse/KAFKA-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877341#comment-16877341 ] Jun Rao commented on KAFKA-8522: [~dhruvilshah] mentioned that the original timestamp of the tombstone

[jira] [Commented] (KAFKA-8522) Tombstones can survive forever

[ https://issues.apache.org/jira/browse/KAFKA-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874578#comment-16874578 ] Jun Rao commented on KAFKA-8522: [~EeveeB], thanks for reporting this. This is related to KAFKA-4545.

[jira] [Commented] (KAFKA-8532) controller-event-thread deadlock with zk-session-expiry-handler0

[ https://issues.apache.org/jira/browse/KAFKA-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865744#comment-16865744 ] Jun Rao commented on KAFKA-8532: [~lbdai3190], if this issue happens again, it would be useful to take a

[jira] [Commented] (KAFKA-8532) controller-event-thread deadlock with zk-session-expiry-handler0

[ https://issues.apache.org/jira/browse/KAFKA-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864184#comment-16864184 ] Jun Rao commented on KAFKA-8532: [~lbdai3190], expiryScheduler.shutdown() is probably not the issue. That

[jira] [Commented] (KAFKA-8532) controller-event-thread deadlock with zk-session-expiry-handler0

[ https://issues.apache.org/jira/browse/KAFKA-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863468#comment-16863468 ] Jun Rao commented on KAFKA-8532: [~lbdai3190], thanks for reporting the issue. From the stacktrace, it

[jira] [Commented] (KAFKA-7504) Broker performance degradation caused by call of sendfile reading disk in network thread

[ https://issues.apache.org/jira/browse/KAFKA-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862569#comment-16862569 ] Jun Rao commented on KAFKA-7504: [~allenxwang], thanks for the update. A couple of more thoughts on this.

[jira] [Commented] (KAFKA-7504) Broker performance degradation caused by call of sendfile reading disk in network thread

[ https://issues.apache.org/jira/browse/KAFKA-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859031#comment-16859031 ] Jun Rao commented on KAFKA-7504: [~allenxwang], thanks for doing the test and sharing the results. Your

[jira] [Commented] (KAFKA-7504) Broker performance degradation caused by call of sendfile reading disk in network thread

[ https://issues.apache.org/jira/browse/KAFKA-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856233#comment-16856233 ] Jun Rao commented on KAFKA-7504: [~allenxwang], there is a PR attached to the jira. I guess we just want

[jira] [Commented] (KAFKA-7983) supporting replication.throttled.replicas in dynamic broker configuration

[ https://issues.apache.org/jira/browse/KAFKA-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812556#comment-16812556 ] Jun Rao commented on KAFKA-7983: [~rahul.mnit], just added you to the contributor list and assigned the

[jira] [Assigned] (KAFKA-7983) supporting replication.throttled.replicas in dynamic broker configuration

[ https://issues.apache.org/jira/browse/KAFKA-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao reassigned KAFKA-7983: -- Assignee: Rahul Agarwal > supporting replication.throttled.replicas in dynamic broker configuration >

[jira] [Commented] (KAFKA-7983) supporting replication.throttled.replicas in dynamic broker configuration

[ https://issues.apache.org/jira/browse/KAFKA-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811005#comment-16811005 ] Jun Rao commented on KAFKA-7983: Probably. But I think the common broker level setting will be just *. >

[jira] [Commented] (KAFKA-7983) supporting replication.throttled.replicas in dynamic broker configuration

[ https://issues.apache.org/jira/browse/KAFKA-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810370#comment-16810370 ] Jun Rao commented on KAFKA-7983: [~huxi_2b], leader.replication.throttled.replicas and 

[jira] [Commented] (KAFKA-8106) Remove unnecessary decompression operation when logValidator do validation.

[ https://issues.apache.org/jira/browse/KAFKA-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805539#comment-16805539 ] Jun Rao commented on KAFKA-8106: [~Flower.min], one of the validation that the broker has to do is to

[jira] [Commented] (KAFKA-7504) Broker performance degradation caused by call of sendfile reading disk in network thread

[ https://issues.apache.org/jira/browse/KAFKA-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802074#comment-16802074 ] Jun Rao commented on KAFKA-7504: [~cwaldrop], thanks for the results. It does seem to be nice

[jira] [Commented] (KAFKA-7504) Broker performance degradation caused by call of sendfile reading disk in network thread

[ https://issues.apache.org/jira/browse/KAFKA-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795523#comment-16795523 ] Jun Rao commented on KAFKA-7504: [~cwaldrop], thanks for helping test this out. It would be useful to

[jira] [Commented] (KAFKA-6029) Controller should wait for the leader migration to finish before ack a ControlledShutdownRequest

[ https://issues.apache.org/jira/browse/KAFKA-6029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16791910#comment-16791910 ] Jun Rao commented on KAFKA-6029: [~hzxa21], do you still plan to work on this? Thanks. > Controller

[jira] [Resolved] (KAFKA-7977) Flaky Test ReassignPartitionsClusterTest#shouldOnlyThrottleMovingReplicas

[ https://issues.apache.org/jira/browse/KAFKA-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-7977. Resolution: Fixed The PR in KAFKA-8018 is merged, which should reduce the chance for ZK session

[jira] [Resolved] (KAFKA-8022) Flaky Test RequestQuotaTest#testExemptRequestTime

[ https://issues.apache.org/jira/browse/KAFKA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-8022. Resolution: Fixed Fix Version/s: (was: 0.11.0.4) 2.2.1

[jira] [Commented] (KAFKA-8022) Flaky Test RequestQuotaTest#testExemptRequestTime

[ https://issues.apache.org/jira/browse/KAFKA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783838#comment-16783838 ] Jun Rao commented on KAFKA-8022: The fsync to ZK txn log can take 10+ secs. Filed

[jira] [Assigned] (KAFKA-8022) Flaky Test RequestQuotaTest#testExemptRequestTime

[ https://issues.apache.org/jira/browse/KAFKA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao reassigned KAFKA-8022: -- Assignee: Jun Rao > Flaky Test RequestQuotaTest#testExemptRequestTime >

[jira] [Commented] (KAFKA-8018) Flaky Test SaslSslAdminClientIntegrationTest#testLegacyAclOpsNeverAffectOrReturnPrefixed

[ https://issues.apache.org/jira/browse/KAFKA-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782210#comment-16782210 ] Jun Rao commented on KAFKA-8018: Created a PR: https://github.com/apache/kafka/pull/6354 > Flaky Test >

[jira] [Assigned] (KAFKA-8018) Flaky Test SaslSslAdminClientIntegrationTest#testLegacyAclOpsNeverAffectOrReturnPrefixed

[ https://issues.apache.org/jira/browse/KAFKA-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao reassigned KAFKA-8018: -- Assignee: Jun Rao > Flaky Test >

[jira] [Resolved] (KAFKA-7956) Avoid blocking in ShutdownableThread.awaitShutdown if the thread has not been started

[ https://issues.apache.org/jira/browse/KAFKA-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-7956. Resolution: Fixed Assignee: Gardner Vickers Fix Version/s: 2.3.0 Merged the PR to trunk.

[jira] [Commented] (KAFKA-7987) a broker's ZK session may die on transient auth failure

[ https://issues.apache.org/jira/browse/KAFKA-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775565#comment-16775565 ] Jun Rao commented on KAFKA-7987: One potential way to fix this is to handle auth failure in 

[jira] [Created] (KAFKA-7987) a broker's ZK session may die on transient auth failure

Jun Rao created KAFKA-7987: -- Summary: a broker's ZK session may die on transient auth failure Key: KAFKA-7987 URL: https://issues.apache.org/jira/browse/KAFKA-7987 Project: Kafka Issue Type:

[jira] [Commented] (KAFKA-7986) distinguish the logging from different ZooKeeperClient instances

[ https://issues.apache.org/jira/browse/KAFKA-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775560#comment-16775560 ] Jun Rao commented on KAFKA-7986: This can potentially be done by passing in a clientID string in the

[jira] [Created] (KAFKA-7986) distinguish the logging from different ZooKeeperClient instances

Jun Rao created KAFKA-7986: -- Summary: distinguish the logging from different ZooKeeperClient instances Key: KAFKA-7986 URL: https://issues.apache.org/jira/browse/KAFKA-7986 Project: Kafka Issue

[jira] [Created] (KAFKA-7983) supporting replication.throttled.replicas in dynamic broker configuration

Jun Rao created KAFKA-7983: -- Summary: supporting replication.throttled.replicas in dynamic broker configuration Key: KAFKA-7983 URL: https://issues.apache.org/jira/browse/KAFKA-7983 Project: Kafka

[jira] [Resolved] (KAFKA-7864) AdminZkClient.validateTopicCreate() should validate that partitions are 0-based

[ https://issues.apache.org/jira/browse/KAFKA-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-7864. Resolution: Fixed Fix Version/s: 2.3.0 Merged the PR to trunk. >

[jira] [Resolved] (KAFKA-7283) mmap indexes lazily and skip sanity check for segments below recovery point

[ https://issues.apache.org/jira/browse/KAFKA-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-7283. Resolution: Fixed Fix Version/s: 2.3.0 Merged the PR to trunk. > mmap indexes lazily and skip

[jira] [Commented] (KAFKA-7888) kafka cluster not recovering - Shrinking ISR from 14,13 to 13 (kafka.cluster.Partition) continously

[ https://issues.apache.org/jira/browse/KAFKA-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758638#comment-16758638 ] Jun Rao commented on KAFKA-7888: [~kemalerden], from the log, the "Cached zkVersion" log started around

[jira] [Resolved] (KAFKA-7837) maybeShrinkIsr may not reflect OfflinePartitions immediately

[ https://issues.apache.org/jira/browse/KAFKA-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-7837. Resolution: Fixed Fix Version/s: 2.2.0 Merged the PR to trunk. > maybeShrinkIsr may not reflect

[jira] [Resolved] (KAFKA-7838) improve logging in Partition.maybeShrinkIsr()

[ https://issues.apache.org/jira/browse/KAFKA-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-7838. Resolution: Fixed Fix Version/s: 2.2.0 Merged the PR to trunk. > improve logging in

[jira] [Commented] (KAFKA-7837) maybeShrinkIsr may not reflect OfflinePartitions immediately

[ https://issues.apache.org/jira/browse/KAFKA-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16751766#comment-16751766 ] Jun Rao commented on KAFKA-7837: [~dhruvilshah], the following is the description of the iterator of

[jira] [Created] (KAFKA-7864) AdminZkClient.validateTopicCreate() should validate that partitions are 0-based

Jun Rao created KAFKA-7864: -- Summary: AdminZkClient.validateTopicCreate() should validate that partitions are 0-based Key: KAFKA-7864 URL: https://issues.apache.org/jira/browse/KAFKA-7864 Project: Kafka

[jira] [Commented] (KAFKA-7837) maybeShrinkIsr may not reflect OfflinePartitions immediately

[ https://issues.apache.org/jira/browse/KAFKA-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746520#comment-16746520 ] Jun Rao commented on KAFKA-7837: @lindong, yes, the approach that you described sounds good. >

[jira] [Created] (KAFKA-7838) improve logging in Partition.maybeShrinkIsr()

Jun Rao created KAFKA-7838: -- Summary: improve logging in Partition.maybeShrinkIsr() Key: KAFKA-7838 URL: https://issues.apache.org/jira/browse/KAFKA-7838 Project: Kafka Issue Type: Improvement

[jira] [Commented] (KAFKA-7837) maybeShrinkIsr may not reflect OfflinePartitions immediately

[ https://issues.apache.org/jira/browse/KAFKA-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745680#comment-16745680 ] Jun Rao commented on KAFKA-7837: One way to improve this is that in maybeShrinkIsr(), for each iterated

[jira] [Created] (KAFKA-7837) maybeShrinkIsr may not reflect OfflinePartitions immediately

Jun Rao created KAFKA-7837: -- Summary: maybeShrinkIsr may not reflect OfflinePartitions immediately Key: KAFKA-7837 URL: https://issues.apache.org/jira/browse/KAFKA-7837 Project: Kafka Issue Type:

[jira] [Commented] (KAFKA-7836) The propagation of log dir failure can be delayed due to slowness in closing the file handles

[ https://issues.apache.org/jira/browse/KAFKA-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745672#comment-16745672 ] Jun Rao commented on KAFKA-7836: [~lindong], it seems that we could call zkClient.propagateLogDirEvent

[jira] [Created] (KAFKA-7836) The propagation of log dir failure can be delayed due to slowness in closing the file handles

Jun Rao created KAFKA-7836: -- Summary: The propagation of log dir failure can be delayed due to slowness in closing the file handles Key: KAFKA-7836 URL: https://issues.apache.org/jira/browse/KAFKA-7836

[jira] [Resolved] (KAFKA-7829) Javadoc should show that AdminClient.alterReplicaLogDirs() is supported in Kafka 1.1.0 or later

[ https://issues.apache.org/jira/browse/KAFKA-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-7829. Resolution: Fixed Fix Version/s: 2.2.0 Merged to trunk. > Javadoc should show that

[jira] [Created] (KAFKA-7829) Inaccurate description for --reassignment-json-file option in ReassignPartitionsCommand

Jun Rao created KAFKA-7829: -- Summary: Inaccurate description for --reassignment-json-file option in ReassignPartitionsCommand Key: KAFKA-7829 URL: https://issues.apache.org/jira/browse/KAFKA-7829 Project:

[jira] [Commented] (KAFKA-7829) Inaccurate description for --reassignment-json-file option in ReassignPartitionsCommand

[ https://issues.apache.org/jira/browse/KAFKA-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744272#comment-16744272 ] Jun Rao commented on KAFKA-7829: [~lindong], could you verify if this is inaccurate? > Inaccurate

[jira] [Commented] (KAFKA-7786) Fast update of leader epoch may stall partition fetching due to FENCED_LEADER_EPOCH

[ https://issues.apache.org/jira/browse/KAFKA-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736415#comment-16736415 ] Jun Rao commented on KAFKA-7786: Great find, Anna. About the fix. I am not sure that we need the protocol

<    1   2   3   4   5   >