[jira] [Created] (KAFKA-3406) CommonClientConfigs.RETRY_BACKOFF_MS_DOC should be more general

Jun Rao created KAFKA-3406: -- Summary: CommonClientConfigs.RETRY_BACKOFF_MS_DOC should be more general Key: KAFKA-3406 URL: https://issues.apache.org/jira/browse/KAFKA-3406 Project: Kafka Issue Type

[jira] [Updated] (KAFKA-3378) Client blocks forever if SocketChannel connects instantly

[ https://issues.apache.org/jira/browse/KAFKA-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3378: --- Priority: Blocker (was: Critical) Thanks for reporting this. Marking this as a blocker for 0.10.0 since it ca

[jira] [Commented] (KAFKA-1215) Rack-Aware replica assignment option

[ https://issues.apache.org/jira/browse/KAFKA-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202369#comment-15202369 ] Jun Rao commented on KAFKA-1215: Great, thanks Allen. > Rack-Aware replica assignment opt

[jira] [Commented] (KAFKA-3205) Error in I/O with host (java.io.EOFException) raised in producer

[ https://issues.apache.org/jira/browse/KAFKA-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197424#comment-15197424 ] Jun Rao commented on KAFKA-3205: [~Mart Haitjema], after the broker closed the idle socket

[jira] [Updated] (KAFKA-3427) broker can return incorrect version of fetch response when the broker hits an unknown exception

[ https://issues.apache.org/jira/browse/KAFKA-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3427: --- Description: In FetchResponse.handleError(), we generate FetchResponse like the following, which always defau

[jira] [Updated] (KAFKA-3006) Make collection default container type for sequences in the consumer API

[ https://issues.apache.org/jira/browse/KAFKA-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3006: --- Priority: Blocker (was: Critical) Marking this an 0.10.0.0 blocker since the vote on KIP-45 has passed. > Ma

[jira] [Updated] (KAFKA-3427) broker can return incorrect version of fetch response when the broker hits an unknown exception

[ https://issues.apache.org/jira/browse/KAFKA-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3427: --- Status: Patch Available (was: Open) > broker can return incorrect version of fetch response when the broker h

[jira] [Updated] (KAFKA-3394) Broker fails to parse Null Metadata in OffsetCommit requests

[ https://issues.apache.org/jira/browse/KAFKA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3394: --- Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 1064 [https:

[jira] [Commented] (KAFKA-3383) Producer should not remove an in flight request before successfully parsing the response.

[ https://issues.apache.org/jira/browse/KAFKA-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201566#comment-15201566 ] Jun Rao commented on KAFKA-3383: [~becket_qin], if this is due to a bug that the broker se

[jira] [Commented] (KAFKA-3383) Producer should not remove an in flight request before successfully parsing the response.

[ https://issues.apache.org/jira/browse/KAFKA-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15200493#comment-15200493 ] Jun Rao commented on KAFKA-3383: [~becket_qin], do you know why the response parsing will

[jira] [Commented] (KAFKA-1215) Rack-Aware replica assignment option

[ https://issues.apache.org/jira/browse/KAFKA-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201709#comment-15201709 ] Jun Rao commented on KAFKA-1215: [~allenxwang], could you also update the changes to ZK st

[jira] [Updated] (KAFKA-3303) Pass partial record metadata to Interceptor onAcknowledgement in case of errors

[ https://issues.apache.org/jira/browse/KAFKA-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3303: --- Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 1015 [https:

[jira] [Created] (KAFKA-3427) broker can return incorrect version of fetch response when the broker hits an unknown exception

Jun Rao created KAFKA-3427: -- Summary: broker can return incorrect version of fetch response when the broker hits an unknown exception Key: KAFKA-3427 URL: https://issues.apache.org/jira/browse/KAFKA-3427 Pro

[jira] [Updated] (KAFKA-3330) Truncate log cleaner offset checkpoint if the log is truncated

[ https://issues.apache.org/jira/browse/KAFKA-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3330: --- Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 1009 [https:

[jira] [Commented] (KAFKA-3427) broker can return incorrect version of fetch response when the broker hits an unknown exception

[ https://issues.apache.org/jira/browse/KAFKA-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203351#comment-15203351 ] Jun Rao commented on KAFKA-3427: [~aauradkar], do you think you could patch this for the 0

[jira] [Commented] (KAFKA-3442) FetchResponse size exceeds max.partition.fetch.bytes

[ https://issues.apache.org/jira/browse/KAFKA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205396#comment-15205396 ] Jun Rao commented on KAFKA-3442: [~dana.powers], could you share you test? Thanks, > Fetc

[jira] [Commented] (KAFKA-3442) FetchResponse size exceeds max.partition.fetch.bytes

[ https://issues.apache.org/jira/browse/KAFKA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205586#comment-15205586 ] Jun Rao commented on KAFKA-3442: [~becket_qin]: It does seem that I can reproduce the issu

[jira] [Commented] (KAFKA-3442) FetchResponse size exceeds max.partition.fetch.bytes

[ https://issues.apache.org/jira/browse/KAFKA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205631#comment-15205631 ] Jun Rao commented on KAFKA-3442: [~becket_qin], yes, the 0.8.2 consumer is able to consume

[jira] [Commented] (KAFKA-3442) FetchResponse size exceeds max.partition.fetch.bytes

[ https://issues.apache.org/jira/browse/KAFKA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15206723#comment-15206723 ] Jun Rao commented on KAFKA-3442: There is another tricky issue to think through. If a clie

[jira] [Commented] (KAFKA-3442) FetchResponse size exceeds max.partition.fetch.bytes

[ https://issues.apache.org/jira/browse/KAFKA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15206867#comment-15206867 ] Jun Rao commented on KAFKA-3442: [~becket_qin], it's probably better if we keep supporting

[jira] [Commented] (KAFKA-3296) All consumer reads hang indefinately

[ https://issues.apache.org/jira/browse/KAFKA-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15206956#comment-15206956 ] Jun Rao commented on KAFKA-3296: [~thecoop1984], it's a bit weird that that the controller

[jira] [Updated] (KAFKA-3301) CommonClientConfigs.METRICS_SAMPLE_WINDOW_MS_DOC is incorrect

[ https://issues.apache.org/jira/browse/KAFKA-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3301: --- Resolution: Fixed Fix Version/s: (was: 0.10.1.0) 0.10.0.0 Status: Reso

[jira] [Created] (KAFKA-3447) partitionState in UpdateMetadataRequest not logged properly state-change log

Jun Rao created KAFKA-3447: -- Summary: partitionState in UpdateMetadataRequest not logged properly state-change log Key: KAFKA-3447 URL: https://issues.apache.org/jira/browse/KAFKA-3447 Project: Kafka

[jira] [Updated] (KAFKA-3447) partitionState in UpdateMetadataRequest not logged properly state-change log

[ https://issues.apache.org/jira/browse/KAFKA-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3447: --- Resolution: Fixed Fix Version/s: 0.10.0.0 Status: Resolved (was: Patch Available) Issue res

[jira] [Updated] (KAFKA-3442) FetchResponse size exceeds max.partition.fetch.bytes

[ https://issues.apache.org/jira/browse/KAFKA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3442: --- Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 1112 [https:

[jira] [Commented] (KAFKA-3442) FetchResponse size exceeds max.partition.fetch.bytes

[ https://issues.apache.org/jira/browse/KAFKA-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15208459#comment-15208459 ] Jun Rao commented on KAFKA-3442: [~dana.powers], this issue is fixed now. Could you verify

[jira] [Commented] (KAFKA-3296) All consumer reads hang indefinately

[ https://issues.apache.org/jira/browse/KAFKA-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15208491#comment-15208491 ] Jun Rao commented on KAFKA-3296: [~thecoop1984], thanks for the results. We will need to f

[jira] [Created] (KAFKA-3467) can't run streams-smoke-test.sh from binary distribution

Jun Rao created KAFKA-3467: -- Summary: can't run streams-smoke-test.sh from binary distribution Key: KAFKA-3467 URL: https://issues.apache.org/jira/browse/KAFKA-3467 Project: Kafka Issue Type: Impro

[jira] [Updated] (KAFKA-3388) Producer should only timeout a batch in the accumulator when metadata is missing.

[ https://issues.apache.org/jira/browse/KAFKA-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3388: --- Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 1056 [https:

[jira] [Created] (KAFKA-3474) add metrics to track replica fetcher timeouts

Jun Rao created KAFKA-3474: -- Summary: add metrics to track replica fetcher timeouts Key: KAFKA-3474 URL: https://issues.apache.org/jira/browse/KAFKA-3474 Project: Kafka Issue Type: Improvement A

[jira] [Updated] (KAFKA-3474) add metrics to track replica fetcher timeouts

[ https://issues.apache.org/jira/browse/KAFKA-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3474: --- Status: Patch Available (was: Open) > add metrics to track replica fetcher timeouts > ---

[jira] [Created] (KAFKA-3492) support quota based on authenticated user name

Jun Rao created KAFKA-3492: -- Summary: support quota based on authenticated user name Key: KAFKA-3492 URL: https://issues.apache.org/jira/browse/KAFKA-3492 Project: Kafka Issue Type: New Feature

[jira] [Commented] (KAFKA-3492) support quota based on authenticated user name

[ https://issues.apache.org/jira/browse/KAFKA-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222367#comment-15222367 ] Jun Rao commented on KAFKA-3492: [~aauradkar], not at this moment. So, feel free to grab t

[jira] [Updated] (KAFKA-3495) `NetworkClient.blockingSendAndReceive` should rely on requestTimeout

[ https://issues.apache.org/jira/browse/KAFKA-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3495: --- Resolution: Fixed Fix Version/s: (was: 0.10.0.0) 0.10.1.0 Status: Reso

[jira] [Updated] (KAFKA-3489) Update request metrics if client closes connection while broker response is in flight

[ https://issues.apache.org/jira/browse/KAFKA-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3489: --- Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 1172 [https:

[jira] [Created] (KAFKA-3530) Making the broker-list option consistent across all tools

Jun Rao created KAFKA-3530: -- Summary: Making the broker-list option consistent across all tools Key: KAFKA-3530 URL: https://issues.apache.org/jira/browse/KAFKA-3530 Project: Kafka Issue Type: Bug

[jira] [Created] (KAFKA-3531) support subnet in ACL tool

Jun Rao created KAFKA-3531: -- Summary: support subnet in ACL tool Key: KAFKA-3531 URL: https://issues.apache.org/jira/browse/KAFKA-3531 Project: Kafka Issue Type: Wish Affects Versions: 0.9.0.1

[jira] [Created] (KAFKA-3532) add principal.builder.class that can extract user from a field

Jun Rao created KAFKA-3532: -- Summary: add principal.builder.class that can extract user from a field Key: KAFKA-3532 URL: https://issues.apache.org/jira/browse/KAFKA-3532 Project: Kafka Issue Type:

[jira] [Commented] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232645#comment-15232645 ] Jun Rao commented on KAFKA-3042: [~delbaeth], [~wushujames], a few things. 1. Supposedly

[jira] [Commented] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238651#comment-15238651 ] Jun Rao commented on KAFKA-3042: The issue seems to be the following. In 0.9.0, we changed

[jira] [Commented] (KAFKA-3410) Unclean leader election and "Halting because log truncation is not allowed"

[ https://issues.apache.org/jira/browse/KAFKA-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239469#comment-15239469 ] Jun Rao commented on KAFKA-3410: [~james cheng], for #2, what you suggested makes sense. I

[jira] [Comment Edited] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239575#comment-15239575 ] Jun Rao edited comment on KAFKA-3042 at 4/13/16 4:45 PM: - [~ijuma]

[jira] [Comment Edited] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239575#comment-15239575 ] Jun Rao edited comment on KAFKA-3042 at 4/13/16 4:45 PM: - [~ijuma]

[jira] [Commented] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239575#comment-15239575 ] Jun Rao commented on KAFKA-3042: [~ismael juma], we fixed a few issues related to soft fai

[jira] [Commented] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241488#comment-15241488 ] Jun Rao commented on KAFKA-3042: [~fpj], I don't think we log the liveBrokers in the leade

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246460#comment-15246460 ] Jun Rao commented on KAFKA-3565: [~becket_qin], in the benchmark result that Ismael posted

[jira] [Commented] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246508#comment-15246508 ] Jun Rao commented on KAFKA-3042: [~fpj], yes, I was confused by that initially too. The fo

[jira] [Comment Edited] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246508#comment-15246508 ] Jun Rao edited comment on KAFKA-3042 at 4/18/16 8:53 PM: - [~fpj],

[jira] [Created] (KAFKA-3579) TopicCommand references outdated consumer property fetch.message.max.bytes

Jun Rao created KAFKA-3579: -- Summary: TopicCommand references outdated consumer property fetch.message.max.bytes Key: KAFKA-3579 URL: https://issues.apache.org/jira/browse/KAFKA-3579 Project: Kafka

[jira] [Created] (KAFKA-3580) improve error logging in ReplicaFetchThread with oversized message

Jun Rao created KAFKA-3580: -- Summary: improve error logging in ReplicaFetchThread with oversized message Key: KAFKA-3580 URL: https://issues.apache.org/jira/browse/KAFKA-3580 Project: Kafka Issue T

[jira] [Created] (KAFKA-3582) remove references to Copcyat from connect property files

Jun Rao created KAFKA-3582: -- Summary: remove references to Copcyat from connect property files Key: KAFKA-3582 URL: https://issues.apache.org/jira/browse/KAFKA-3582 Project: Kafka Issue Type: Improv

[jira] [Updated] (KAFKA-3582) remove references to Copcyat from connect property files

[ https://issues.apache.org/jira/browse/KAFKA-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3582: --- Resolution: Fixed Fix Version/s: 0.10.0.0 Status: Resolved (was: Patch Available) Issue res

[jira] [Commented] (KAFKA-3042) updateIsr should stop after failed several times due to zkVersion issue

[ https://issues.apache.org/jira/browse/KAFKA-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15248954#comment-15248954 ] Jun Rao commented on KAFKA-3042: Currently, the main differences between LeaderAndIsrReque

[jira] [Commented] (KAFKA-3128) Add metrics for ZooKeeper events

[ https://issues.apache.org/jira/browse/KAFKA-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15254407#comment-15254407 ] Jun Rao commented on KAFKA-3128: ZKClient probably doesn't expose connection loss events.

[jira] [Commented] (KAFKA-3128) Add metrics for ZooKeeper events

[ https://issues.apache.org/jira/browse/KAFKA-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264445#comment-15264445 ] Jun Rao commented on KAFKA-3128: [~fpj], yes, it's a good idea to track both session expir

[jira] [Comment Edited] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267803#comment-15267803 ] Jun Rao edited comment on KAFKA-3565 at 5/3/16 12:25 AM: - [~becket

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267803#comment-15267803 ] Jun Rao commented on KAFKA-3565: Jiangjie, thanks for the results. It seems that the overa

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268985#comment-15268985 ] Jun Rao commented on KAFKA-3565: [~becket_qin], thanks for the new results. Are the stats

[jira] [Updated] (KAFKA-3517) Document configuration of SASL/PLAIN and multiple mechanisms

[ https://issues.apache.org/jira/browse/KAFKA-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3517: --- Resolution: Fixed Fix Version/s: (was: 0.10.1.0) 0.10.0.0 Status: Reso

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269113#comment-15269113 ] Jun Rao commented on KAFKA-3565: [~becket_qin], thanks for the explanation. The results no

[jira] [Updated] (KAFKA-3128) Add metrics for ZooKeeper events

[ https://issues.apache.org/jira/browse/KAFKA-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3128: --- Resolution: Fixed Fix Version/s: (was: 0.10.1.0) 0.10.0.0 Status: Reso

[jira] [Created] (KAFKA-3653) expose the queue size in ControllerChannelManager

Jun Rao created KAFKA-3653: -- Summary: expose the queue size in ControllerChannelManager Key: KAFKA-3653 URL: https://issues.apache.org/jira/browse/KAFKA-3653 Project: Kafka Issue Type: Improvement

[jira] [Commented] (KAFKA-3565) bceunbfjcvtdvidckvjrrcklvtdnjgvlj

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269805#comment-15269805 ] Jun Rao commented on KAFKA-3565: [~becket_qin], thanks for the new results. Could you also

[jira] [Commented] (KAFKA-3173) Error while moving some partitions to OnlinePartition state

[ https://issues.apache.org/jira/browse/KAFKA-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269978#comment-15269978 ] Jun Rao commented on KAFKA-3173: [~fpj], thanks the analysis. It seems that the whole onCo

[jira] [Commented] (KAFKA-725) Broker Exception: Attempt to read with a maximum offset less than start offset

[ https://issues.apache.org/jira/browse/KAFKA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270789#comment-15270789 ] Jun Rao commented on KAFKA-725: --- [~Srdo], thanks for the patch. It's still not very clear to

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15271185#comment-15271185 ] Jun Rao commented on KAFKA-3565: [~becket_qin], thanks for the results. As I was looking a

[jira] [Resolved] (KAFKA-3652) Return error response for unsupported version of ApiVersionsRequest

[ https://issues.apache.org/jira/browse/KAFKA-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-3652. Resolution: Fixed Committed the PR to 0.10.0. > Return error response for unsupported version of ApiVersion

[jira] [Reopened] (KAFKA-725) Broker Exception: Attempt to read with a maximum offset less than start offset

[ https://issues.apache.org/jira/browse/KAFKA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao reopened KAFKA-725: --- Reopen this jira since the fix exposes a new issue. When the leader switches (say due to leader balancing), the ne

[jira] [Commented] (KAFKA-725) Broker Exception: Attempt to read with a maximum offset less than start offset

[ https://issues.apache.org/jira/browse/KAFKA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272591#comment-15272591 ] Jun Rao commented on KAFKA-725: --- Yes, I agree. If the requested offset is > MaxOffset, it's b

[jira] [Commented] (KAFKA-3330) Truncate log cleaner offset checkpoint if the log is truncated

[ https://issues.apache.org/jira/browse/KAFKA-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272621#comment-15272621 ] Jun Rao commented on KAFKA-3330: If you see the issue now, the simplest thing is to remove

[jira] [Commented] (KAFKA-3173) Error while moving some partitions to OnlinePartition state

[ https://issues.apache.org/jira/browse/KAFKA-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272603#comment-15272603 ] Jun Rao commented on KAFKA-3173: [~fpj], yes, I agree that the lock there is confusing. Mo

[jira] [Updated] (KAFKA-725) Broker Exception: Attempt to read with a maximum offset less than start offset

[ https://issues.apache.org/jira/browse/KAFKA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-725: -- Priority: Blocker (was: Major) > Broker Exception: Attempt to read with a maximum offset less than start offset

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272750#comment-15272750 ] Jun Rao commented on KAFKA-3565: [~becket_qin], thanks for the latest consumer results. Ye

[jira] [Commented] (KAFKA-3587) LogCleaner fails due to incorrect offset map computation on a replica

[ https://issues.apache.org/jira/browse/KAFKA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15273457#comment-15273457 ] Jun Rao commented on KAFKA-3587: [~alekar] and [~liquanpei], thanks for both your patches.

[jira] [Commented] (KAFKA-3587) LogCleaner fails due to incorrect offset map computation on a replica

[ https://issues.apache.org/jira/browse/KAFKA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15273606#comment-15273606 ] Jun Rao commented on KAFKA-3587: [~alekar], I think [~ecomar] is suggesting a potentially

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[ https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274195#comment-15274195 ] Jun Rao commented on KAFKA-3665: Thanks for the patch. A couple of questions. 1. Is the r

[jira] [Commented] (KAFKA-3587) LogCleaner fails due to incorrect offset map computation on a replica

[ https://issues.apache.org/jira/browse/KAFKA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274372#comment-15274372 ] Jun Rao commented on KAFKA-3587: [~ecomar], thanks for the explanation. I am not sure abou

[jira] [Commented] (KAFKA-3587) LogCleaner fails due to incorrect offset map computation on a replica

[ https://issues.apache.org/jira/browse/KAFKA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274442#comment-15274442 ] Jun Rao commented on KAFKA-3587: Yes, let's first agree upon the best approach on the jira

[jira] [Commented] (KAFKA-3587) LogCleaner fails due to incorrect offset map computation on a replica

[ https://issues.apache.org/jira/browse/KAFKA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274526#comment-15274526 ] Jun Rao commented on KAFKA-3587: [~alekar], note that when copying retained messages to ne

[jira] [Created] (KAFKA-3670) ControlledShutdownLeaderSelector should pick the preferred replica as the new leader, if possible

Jun Rao created KAFKA-3670: -- Summary: ControlledShutdownLeaderSelector should pick the preferred replica as the new leader, if possible Key: KAFKA-3670 URL: https://issues.apache.org/jira/browse/KAFKA-3670 P

[jira] [Commented] (KAFKA-3587) LogCleaner fails due to incorrect offset map computation on a replica

[ https://issues.apache.org/jira/browse/KAFKA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274677#comment-15274677 ] Jun Rao commented on KAFKA-3587: [~ecomar], yes, what you described matches my expectation

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274917#comment-15274917 ] Jun Rao commented on KAFKA-3565: [~becket_qin], any new findings on the consumer performan

[jira] [Updated] (KAFKA-3670) ControlledShutdownLeaderSelector should pick the preferred replica as the new leader, if possible

[ https://issues.apache.org/jira/browse/KAFKA-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3670: --- Resolution: Fixed Status: Resolved (was: Patch Available) Issue resolved by pull request 1338 [https:

[jira] [Commented] (KAFKA-3587) LogCleaner fails due to incorrect offset map computation on a replica

[ https://issues.apache.org/jira/browse/KAFKA-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275741#comment-15275741 ] Jun Rao commented on KAFKA-3587: [~guozhang], I don't think (a:4) will ever be duplicated

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275793#comment-15275793 ] Jun Rao commented on KAFKA-3565: [~becket_qin], thanks for the latest analysis. The differ

[jira] [Commented] (KAFKA-3665) Default ssl.endpoint.identification.algorithm should be https

[ https://issues.apache.org/jira/browse/KAFKA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275926#comment-15275926 ] Jun Rao commented on KAFKA-3665: Interesting, the difference is that in https, if a VIP is

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275957#comment-15275957 ] Jun Rao commented on KAFKA-3565: [~becket_qin], thanks for confirming this. I guess defaul

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275959#comment-15275959 ] Jun Rao commented on KAFKA-3565: [~becket_qin], also, it seems that you patched ProducerPe

[jira] [Commented] (KAFKA-3693) Race condition between highwatermark-checkpoint thread and handleLeaderAndIsrRequest at broker start-up

[ https://issues.apache.org/jira/browse/KAFKA-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15279310#comment-15279310 ] Jun Rao commented on KAFKA-3693: [~maysamyabandeh], yes, the logic in the controller is th

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15279536#comment-15279536 ] Jun Rao commented on KAFKA-3565: [~guozhang], do you want to patch the producer to use the

[jira] [Commented] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280213#comment-15280213 ] Jun Rao commented on KAFKA-3565: Since that's an existing issue, perhaps file a new jira?

[jira] [Resolved] (KAFKA-3565) Producer's throughput lower with compressed data after KIP-31/32

[ https://issues.apache.org/jira/browse/KAFKA-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-3565. Resolution: Fixed Fix Version/s: 0.10.0.0 Issue resolved by pull request 1372 [https://github.com/apa

[jira] [Commented] (KAFKA-1981) Make log compaction point configurable

[ https://issues.apache.org/jira/browse/KAFKA-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15284004#comment-15284004 ] Jun Rao commented on KAFKA-1981: [~ewasserman], thanks for the KIP. This seems like a usef

[jira] [Commented] (KAFKA-2903) FileMessageSet's read method maybe has problem when start is not zero

[ https://issues.apache.org/jira/browse/KAFKA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046379#comment-15046379 ] Jun Rao commented on KAFKA-2903: Yes, the current logic is a bit confusing, but is correct

[jira] [Resolved] (KAFKA-2668) Add a metric that records the total number of metrics

[ https://issues.apache.org/jira/browse/KAFKA-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-2668. Resolution: Fixed Issue resolved by pull request 328 [https://github.com/apache/kafka/pull/328] > Add a met

[jira] [Commented] (KAFKA-2903) FileMessageSet's read method maybe has problem when start is not zero

[ https://issues.apache.org/jira/browse/KAFKA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048946#comment-15048946 ] Jun Rao commented on KAFKA-2903: Yes, I think that will be fine too. > FileMessageSet's r

[jira] [Created] (KAFKA-3010) include error code when logging an error when ack = 0

Jun Rao created KAFKA-3010: -- Summary: include error code when logging an error when ack = 0 Key: KAFKA-3010 URL: https://issues.apache.org/jira/browse/KAFKA-3010 Project: Kafka Issue Type: Improveme

[jira] [Created] (KAFKA-3027) Kafka metrics can be stale if there is no new update

Jun Rao created KAFKA-3027: -- Summary: Kafka metrics can be stale if there is no new update Key: KAFKA-3027 URL: https://issues.apache.org/jira/browse/KAFKA-3027 Project: Kafka Issue Type: Bug

[jira] [Updated] (KAFKA-3027) Kafka metrics can be stale if there is no new update

[ https://issues.apache.org/jira/browse/KAFKA-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-3027: --- Affects Version/s: 0.9.0.0 > Kafka metrics can be stale if there is no new update > --

[jira] [Resolved] (KAFKA-3027) Kafka metrics can be stale if there is no new update

[ https://issues.apache.org/jira/browse/KAFKA-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao resolved KAFKA-3027. Resolution: Not A Problem [~jkreps], yes, you are right. Tried the console producer and the metrics are up

<    3   4   5   6   7   8   9   10   11   12   >