[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_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-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: 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 ] 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 ] Joel Koshy updated KAFKA-2241: -- Status: In Progress (was: Patch Available) > 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 ] 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)
