[jira] [Created] (KAFKA-1010) Concurrency issue in getCluster() causes rebalance failure and dead consumer

Sam Meder created KAFKA-1010: Summary: Concurrency issue in getCluster() causes rebalance failure and dead consumer Key: KAFKA-1010 URL: https://issues.apache.org/jira/browse/KAFKA-1010 Project: Kafka

[jira] [Updated] (KAFKA-1010) Concurrency issue in getCluster() causes rebalance failure and dead consumer

[ https://issues.apache.org/jira/browse/KAFKA-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Meder updated KAFKA-1010: - Attachment: get_cluster_0_8.patch Simply move getCluster() call intro retry loop and eliminate second cal

[jira] [Updated] (KAFKA-1010) Concurrency issue in getCluster() causes rebalance failure and dead consumer

[ https://issues.apache.org/jira/browse/KAFKA-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Meder updated KAFKA-1010: - Status: Patch Available (was: Open) > Concurrency issue in getCluster() causes rebalance failure and

[jira] [Commented] (KAFKA-1008) Unmap before resizing

[ https://issues.apache.org/jira/browse/KAFKA-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741035#comment-13741035 ] Jay Kreps commented on KAFKA-1008: -- Yeah, the problem is reads continue while the log is

[jira] [Commented] (KAFKA-1008) Unmap before resizing

[ https://issues.apache.org/jira/browse/KAFKA-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741037#comment-13741037 ] Jay Kreps commented on KAFKA-1008: -- Here is a list of os.name values (at least according

[jira] [Commented] (KAFKA-1010) Concurrency issue in getCluster() causes rebalance failure and dead consumer

[ https://issues.apache.org/jira/browse/KAFKA-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741148#comment-13741148 ] Guozhang Wang commented on KAFKA-1010: -- This looks good to me. If the broker ephemera

[jira] [Commented] (KAFKA-992) Double Check on Broker Registration to Avoid False NodeExist Exception

[ https://issues.apache.org/jira/browse/KAFKA-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741179#comment-13741179 ] Neha Narkhede commented on KAFKA-992: - Overall, v11 is a good refactor. Few minor forma

[jira] [Commented] (KAFKA-992) Double Check on Broker Registration to Avoid False NodeExist Exception

[ https://issues.apache.org/jira/browse/KAFKA-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741206#comment-13741206 ] Jun Rao commented on KAFKA-992: --- Thanks for patch v11. Much better, but can still be improved

[jira] [Commented] (KAFKA-527) Compression support does numerous byte copies

[ https://issues.apache.org/jira/browse/KAFKA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741294#comment-13741294 ] Guozhang Wang commented on KAFKA-527: - One alternative approach would be like this: Cu

Re: compression performance

Here is a comment from Guozhong on this issue. He posted it on the compression byte-copying issue, but it is really about not needing to do compression. His suggestion is interesting though it ends up pushing more complexity into consumers. Guozhang Wang commented on KAFKA-527: ---

[jira] Subscription: outstanding kafka patches

Issue Subscription Filter: outstanding kafka patches (71 issues) The list of outstanding kafka patches Subscriber: kafka-mailing-list Key Summary KAFKA-1010 Concurrency issue in getCluster() causes rebalance failure and dead consumer https://issues.apache.org/jira/bro

Re: compression performance

We need to first decide on the right behavior before optimizing on the implementation. Few key goals that I would put forward are - 1. Decoupling compression codec of the producer and the log 2. Ensuring message validity by the server on receiving bytes. This is done by the iterator today and thi

[jira] [Created] (KAFKA-1011) Decompression and re-compression on MirrorMaker could result in messages being dropped in the pipeline

Guozhang Wang created KAFKA-1011: Summary: Decompression and re-compression on MirrorMaker could result in messages being dropped in the pipeline Key: KAFKA-1011 URL: https://issues.apache.org/jira/browse/KAFKA-10

[jira] [Commented] (KAFKA-992) Double Check on Broker Registration to Avoid False NodeExist Exception

[ https://issues.apache.org/jira/browse/KAFKA-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741587#comment-13741587 ] Guozhang Wang commented on KAFKA-992: - Thanks for the comments, Neha, Jun. And sorry fo

[jira] [Updated] (KAFKA-992) Double Check on Broker Registration to Avoid False NodeExist Exception

[ https://issues.apache.org/jira/browse/KAFKA-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang updated KAFKA-992: Attachment: KAFKA-992.v12.patch > Double Check on Broker Registration to Avoid False NodeExist E

Re: compression performance

I would generally agree with the key goals you've suggested. I'm just coming to this discussion after some recent testing with 0.8 so I may be missing some background. The reference I found to this discussion is the JIRA issue below. Please let me know if there are others things I should look at.

Re: compression performance

Sriram, I think I agree. Guozhang's proposal is clever but it exposes a lot of complexity to the consumer. But I think it is good to have the complete discussion. Chris, we will certainly not mess up the uncompressed case, don't worry. I think your assumption is that compression needs to be slow.

[jira] [Commented] (KAFKA-1008) Unmap before resizing

[ https://issues.apache.org/jira/browse/KAFKA-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741938#comment-13741938 ] Elizabeth Wei commented on KAFKA-1008: -- Sounds like a good idea to have lock reads. D