[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-2241: --- Resolution: Fixed Fix Version/s: 0.8.3 Status: Resolved (was: Patch Available) Thanks for the patch. +1 and committed to trunk. AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Labels: quotas Fix For: 0.8.3 Attachments: KAFKA-2241.patch, KAFKA-2241_2015-06-03_15:30:35.patch, KAFKA-2241_2015-07-09_15:35:49.patch, KAFKA-2241_2015-07-13_13:30:07.patch, KAFKA-2241_2015-07-13_14:51:42.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-2241: Attachment: KAFKA-2241_2015-07-13_13:30:07.patch AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Labels: quotas Attachments: KAFKA-2241.patch, KAFKA-2241_2015-06-03_15:30:35.patch, KAFKA-2241_2015-07-09_15:35:49.patch, KAFKA-2241_2015-07-13_13:30:07.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-2241: Attachment: KAFKA-2241_2015-07-13_14:51:42.patch AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Labels: quotas Attachments: KAFKA-2241.patch, KAFKA-2241_2015-06-03_15:30:35.patch, KAFKA-2241_2015-07-09_15:35:49.patch, KAFKA-2241_2015-07-13_13:30:07.patch, KAFKA-2241_2015-07-13_14:51:42.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-2241: Attachment: KAFKA-2241_2015-07-09_15:35:49.patch AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Labels: quotas Attachments: KAFKA-2241.patch, KAFKA-2241_2015-06-03_15:30:35.patch, KAFKA-2241_2015-07-09_15:35:49.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-2241: Status: Patch Available (was: In Progress) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Labels: quotas Attachments: KAFKA-2241.patch, KAFKA-2241_2015-06-03_15:30:35.patch, KAFKA-2241_2015-07-09_15:35:49.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Rao updated KAFKA-2241: --- Reviewer: Jun Rao AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Labels: quotas Attachments: KAFKA-2241.patch, KAFKA-2241_2015-06-03_15:30:35.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aditya Auradkar updated KAFKA-2241: --- Labels: quotas (was: ) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Labels: quotas Attachments: KAFKA-2241.patch, KAFKA-2241_2015-06-03_15:30:35.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-2241: Attachment: KAFKA-2241_2015-06-03_15:30:35.patch AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Attachments: KAFKA-2241.patch, KAFKA-2241_2015-06-03_15:30:35.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-2241: Attachment: KAFKA-2241.patch AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Attachments: KAFKA-2241.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-2241: Status: Patch Available (was: Open) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Attachments: KAFKA-2241.patch, client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-2241) AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer)
[ https://issues.apache.org/jira/browse/KAFKA-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-2241: Attachment: client.java server.java Run server before client. Then check if channel.read() will unblock after the thread is interrupted. AbstractFetcherThread.shutdown() should not block on ReadableByteChannel.read(buffer) - Key: KAFKA-2241 URL: https://issues.apache.org/jira/browse/KAFKA-2241 Project: Kafka Issue Type: Bug Reporter: Dong Lin Assignee: Dong Lin Attachments: client.java, server.java This is likely a bug from Java. This affects Kafka and here is the patch to fix it. Here is the description of the bug. By description of SocketChannel in Java 7 Documentation. If another thread interrupts the current thread while the read operation is in progress, the it should closes the channel and throw ClosedByInterruptException. However, we find that interrupting the thread will not unblock the channel immediately. Instead, it waits for response or socket timeout before throwing an exception. This will cause problem in the following scenario. Suppose one console_consumer_1 is reading from a topic, and due to quota delay or whatever reason, it block on channel.read(buffer). At this moment, another console_consumer_2 joins and triggers rebalance at console_consumer_1. But consumer_1 will block waiting on the channel.read before it can release partition ownership, causing consumer_2 to fail after a number of failed attempts to obtain partition ownership. In other words, AbstractFetcherThread.shutdown() is not guaranteed to shutdown due to this bug. The problem is confirmed with Java 1.7 and java 1.6. To check it by yourself, you can use the attached server.java and client.java -- start the server before the client and see if client unblock after interruption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
