[jira] [Commented] (KAFKA-266) Kafka web console
[ https://issues.apache.org/jira/browse/KAFKA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645410#comment-13645410 ] Samir Madhavan commented on KAFKA-266: -- This would be absolutely great to have. Wanted to know, how it has progressed? Kafka web console - Key: KAFKA-266 URL: https://issues.apache.org/jira/browse/KAFKA-266 Project: Kafka Issue Type: New Feature Components: contrib Reporter: Evan Chan Labels: project Original Estimate: 672h Remaining Estimate: 672h This issue is created to track a community-contributed Kafka Web UI. Here is an initial list of goals: - Be able to easily see which brokers are up - Be able to see lists of topics, connected producers, consumer groups, connected consumers - Be able to see, for each consumer/partition, its offset, and more importantly, # of bytes unconsumed (== largest offset for partition - current offset) - (Wish list) have a graphical view of the offsets - (Wish list) be able to clean up consumer state, such as stale claimed partitions List of challenges/questions: - Which framework? Play! for Scala? - Is all the data available from JMX and ZK? Hopefully, watching the files on the filesystem can be avoided - How to handle large numbers of topics, partitions, consumers, etc. efficiently -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (KAFKA-876) Produce request: Leader not local for partition [test,0] on broker 0
[ https://issues.apache.org/jira/browse/KAFKA-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645580#comment-13645580 ] Rob Withers commented on KAFKA-876: --- The property is named log.dir, not log.dirs in my properties file. Here is what I have: # Log Basics # # The directory under which to store log files log.dir=/kafka8-tmp/kafka-logs Produce request: Leader not local for partition [test,0] on broker 0 - Key: KAFKA-876 URL: https://issues.apache.org/jira/browse/KAFKA-876 Project: Kafka Issue Type: Bug Components: clients, replication Affects Versions: 0.8 Environment: Windows Reporter: Yin Yin Assignee: Neha Narkhede Priority: Blocker Follow the quick start to open zookeeper, one broker, one producer and one consumer. In the producer console, there is an LeaderNotAvailableException for the first message, and the broker complains Produce request: Leader not local for partition [test,0] on broker 0 for all following messages. Kafka-List-Topic shows [2013-04-25 10:21:24,689] INFO zookeeper state changed (SyncConnected) (org.I0Itec.zkclient.ZkClient) topic: test partition: 0leader: 0 replicas: 0 isr: 0. With --unavailable-partitions option, it doesn't list any topic. =Broker Log= Set JMX_PORT to default value : C:\Projects\Kafka\kafka\bin\.. log4j:ERROR Failed to rename [server.log] to [server.log.2013-04-25-09]. [2013-04-25 10:08:49,531] INFO Verifying properties (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property socket.send.buffer.bytes is overridden to 1048576 (kafka.utils.VerifiablePropert ies) [2013-04-25 10:08:49,578] INFO Property socket.request.max.bytes is overridden to 104857600 (kafka.utils.VerifiablePrope rties) [2013-04-25 10:08:49,578] INFO Property log.dir is overridden to /tmp/kafka-logs (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property log.cleanup.interval.mins is overridden to 1 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property log.retention.hours is overridden to 168 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property num.io.threads is overridden to 2 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property broker.id is overridden to 0 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] WARN Property kafka.csv.metrics.reporter.enabled is not valid (kafka.utils.VerifiablePropertie s) [2013-04-25 10:08:49,578] INFO Property port is overridden to 9092 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property log.flush.interval.messages is overridden to 1 (kafka.utils.VerifiableProper ties) [2013-04-25 10:08:49,578] INFO Property zk.connection.timeout.ms is overridden to 100 (kafka.utils.VerifiablePropert ies) [2013-04-25 10:08:49,578] WARN Property kafka.metrics.reporters is not valid (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] WARN Property kafka.csv.metrics.dir is not valid (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property log.flush.interval.ms is overridden to 1000 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] WARN Property kafka.metrics.polling.interval.secs is not valid (kafka.utils.VerifiableProperti es) [2013-04-25 10:08:49,578] INFO Property num.network.threads is overridden to 2 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property socket.receive.buffer.bytes is overridden to 1048576 (kafka.utils.VerifiableProp erties) [2013-04-25 10:08:49,578] INFO Property log.segment.bytes is overridden to 536870912 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property zk.connect is overridden to localhost:2181 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,594] INFO Property num.partitions is overridden to 1 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,609] INFO [Kafka Server 0], starting (kafka.server.KafkaServer) [2013-04-25 10:08:49,625] INFO [Log Manager on Broker 0] Log directory 'C:\tmp\kafka-logs' not found, creating it. (kafk a.log.LogManager) [2013-04-25 10:08:49,625] INFO [Log Manager on Broker 0] Starting log cleaner every 6 ms (kafka.log.LogManager) [2013-04-25 10:08:49,640] INFO [Log Manager on Broker 0] Starting log flusher every 3000 ms with the following overrides Map() (kafka.log.LogManager) [2013-04-25 10:08:49,656] INFO Awaiting socket connections on 0.0.0.0:9092. (kafka.network.Acceptor) [2013-04-25 10:08:49,656] INFO [Socket Server on Broker 0], started
[jira] [Commented] (KAFKA-876) Produce request: Leader not local for partition [test,0] on broker 0
[ https://issues.apache.org/jira/browse/KAFKA-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645676#comment-13645676 ] Jun Rao commented on KAFKA-876: --- It seems that log.dir.getParent() returns a path with forward slash \kafka8-tmp\kafka-logs. Could you use forward slash in log.dir instead of backward slash? Produce request: Leader not local for partition [test,0] on broker 0 - Key: KAFKA-876 URL: https://issues.apache.org/jira/browse/KAFKA-876 Project: Kafka Issue Type: Bug Components: clients, replication Affects Versions: 0.8 Environment: Windows Reporter: Yin Yin Assignee: Neha Narkhede Priority: Blocker Follow the quick start to open zookeeper, one broker, one producer and one consumer. In the producer console, there is an LeaderNotAvailableException for the first message, and the broker complains Produce request: Leader not local for partition [test,0] on broker 0 for all following messages. Kafka-List-Topic shows [2013-04-25 10:21:24,689] INFO zookeeper state changed (SyncConnected) (org.I0Itec.zkclient.ZkClient) topic: test partition: 0leader: 0 replicas: 0 isr: 0. With --unavailable-partitions option, it doesn't list any topic. =Broker Log= Set JMX_PORT to default value : C:\Projects\Kafka\kafka\bin\.. log4j:ERROR Failed to rename [server.log] to [server.log.2013-04-25-09]. [2013-04-25 10:08:49,531] INFO Verifying properties (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property socket.send.buffer.bytes is overridden to 1048576 (kafka.utils.VerifiablePropert ies) [2013-04-25 10:08:49,578] INFO Property socket.request.max.bytes is overridden to 104857600 (kafka.utils.VerifiablePrope rties) [2013-04-25 10:08:49,578] INFO Property log.dir is overridden to /tmp/kafka-logs (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property log.cleanup.interval.mins is overridden to 1 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property log.retention.hours is overridden to 168 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property num.io.threads is overridden to 2 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property broker.id is overridden to 0 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] WARN Property kafka.csv.metrics.reporter.enabled is not valid (kafka.utils.VerifiablePropertie s) [2013-04-25 10:08:49,578] INFO Property port is overridden to 9092 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property log.flush.interval.messages is overridden to 1 (kafka.utils.VerifiableProper ties) [2013-04-25 10:08:49,578] INFO Property zk.connection.timeout.ms is overridden to 100 (kafka.utils.VerifiablePropert ies) [2013-04-25 10:08:49,578] WARN Property kafka.metrics.reporters is not valid (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] WARN Property kafka.csv.metrics.dir is not valid (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property log.flush.interval.ms is overridden to 1000 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] WARN Property kafka.metrics.polling.interval.secs is not valid (kafka.utils.VerifiableProperti es) [2013-04-25 10:08:49,578] INFO Property num.network.threads is overridden to 2 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property socket.receive.buffer.bytes is overridden to 1048576 (kafka.utils.VerifiableProp erties) [2013-04-25 10:08:49,578] INFO Property log.segment.bytes is overridden to 536870912 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,578] INFO Property zk.connect is overridden to localhost:2181 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,594] INFO Property num.partitions is overridden to 1 (kafka.utils.VerifiableProperties) [2013-04-25 10:08:49,609] INFO [Kafka Server 0], starting (kafka.server.KafkaServer) [2013-04-25 10:08:49,625] INFO [Log Manager on Broker 0] Log directory 'C:\tmp\kafka-logs' not found, creating it. (kafk a.log.LogManager) [2013-04-25 10:08:49,625] INFO [Log Manager on Broker 0] Starting log cleaner every 6 ms (kafka.log.LogManager) [2013-04-25 10:08:49,640] INFO [Log Manager on Broker 0] Starting log flusher every 3000 ms with the following overrides Map() (kafka.log.LogManager) [2013-04-25 10:08:49,656] INFO Awaiting socket connections on 0.0.0.0:9092. (kafka.network.Acceptor) [2013-04-25 10:08:49,656] INFO [Socket Server on Broker 0], started (kafka.network.SocketServer) [2013-04-25 10:08:49,672] INFO connecting to ZK: localhost:2181
[jira] [Commented] (KAFKA-890) The list of brokers for fetching metadata should be shuffled
[ https://issues.apache.org/jira/browse/KAFKA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645736#comment-13645736 ] Joel Koshy commented on KAFKA-890: -- +1 It is worth noting that this is useful even in the presence of a VIP since the consumers don't currently use a VIP to to look up metadata. The list of brokers for fetching metadata should be shuffled - Key: KAFKA-890 URL: https://issues.apache.org/jira/browse/KAFKA-890 Project: Kafka Issue Type: Bug Components: core Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Blocker Labels: kafka-0.8, p1 Attachments: kafka-890.patch The list of brokers in the metadata request is never shuffled. Which means that if some clients are not using a VIP for metadata requests, the first broker ends up servicing most metadata requests, leaving imbalanced load on the brokers. This issue is even more pronounced when there are several thousand clients talking to a cluster each using a broker list to fetch metadata. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (KAFKA-860) Replica fetcher thread errors out and dies during rolling bounce of cluster
[ https://issues.apache.org/jira/browse/KAFKA-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede closed KAFKA-860. --- Replica fetcher thread errors out and dies during rolling bounce of cluster --- Key: KAFKA-860 URL: https://issues.apache.org/jira/browse/KAFKA-860 Project: Kafka Issue Type: Bug Components: replication Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Blocker Labels: kafka-0.8, p1 Attachments: kafka-860-v1.patch, kafka-860-v2.patch 2013/04/10 20:04:32.071 ERROR [ReplicaFetcherThread] [ReplicaFetcherThread-0-272] [kafka] [] [ReplicaFetcherThread-0-272], Error due to kafka.common.KafkaException: error processing data for topic PageViewEvent partititon 3 offset 2482625623 at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$4.apply(AbstractFetcherThread.scala:135) at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$4.apply(AbstractFetcherThread.scala:113) at scala.collection.immutable.Map$Map1.foreach(Map.scala:105) at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:113) at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:89) at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:51) Caused by: java.lang.RuntimeException: Offset mismatch: fetched offset = 2482625623, log end offset = 2482625631. at kafka.server.ReplicaFetcherThread.processPartitionData(ReplicaFetcherThread.scala:49) at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$4.apply(AbstractFetcherThread.scala:132) ... 5 more This causes replica fetcher thread to shut down -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KAFKA-860) Replica fetcher thread errors out and dies during rolling bounce of cluster
[ https://issues.apache.org/jira/browse/KAFKA-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-860: Resolution: Fixed Status: Resolved (was: Patch Available) v1 fixes the issue Replica fetcher thread errors out and dies during rolling bounce of cluster --- Key: KAFKA-860 URL: https://issues.apache.org/jira/browse/KAFKA-860 Project: Kafka Issue Type: Bug Components: replication Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Blocker Labels: kafka-0.8, p1 Attachments: kafka-860-v1.patch, kafka-860-v2.patch 2013/04/10 20:04:32.071 ERROR [ReplicaFetcherThread] [ReplicaFetcherThread-0-272] [kafka] [] [ReplicaFetcherThread-0-272], Error due to kafka.common.KafkaException: error processing data for topic PageViewEvent partititon 3 offset 2482625623 at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$4.apply(AbstractFetcherThread.scala:135) at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$4.apply(AbstractFetcherThread.scala:113) at scala.collection.immutable.Map$Map1.foreach(Map.scala:105) at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:113) at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:89) at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:51) Caused by: java.lang.RuntimeException: Offset mismatch: fetched offset = 2482625623, log end offset = 2482625631. at kafka.server.ReplicaFetcherThread.processPartitionData(ReplicaFetcherThread.scala:49) at kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$4.apply(AbstractFetcherThread.scala:132) ... 5 more This causes replica fetcher thread to shut down -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KAFKA-817) Implement a zookeeper path-based controlled shutdown tool
[ https://issues.apache.org/jira/browse/KAFKA-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-817: Labels: (was: kafka-0.8 p2) Implement a zookeeper path-based controlled shutdown tool - Key: KAFKA-817 URL: https://issues.apache.org/jira/browse/KAFKA-817 Project: Kafka Issue Type: Bug Components: controller, tools Affects Versions: 0.8 Reporter: Joel Koshy Assignee: Neha Narkhede The controlled shutdown tool currently depends on jmxremote.port being exposed. Apparently, this is often not exposed in production environments and makes the script unusable. We can move to a zk-based approach in which the controller watches a path that lists shutting down brokers. This will also make it consistent with the pattern used in some of the other replication-related tools. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KAFKA-817) Implement a zookeeper path-based controlled shutdown tool
[ https://issues.apache.org/jira/browse/KAFKA-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-817: Affects Version/s: (was: 0.8) 0.8.1 Implement a zookeeper path-based controlled shutdown tool - Key: KAFKA-817 URL: https://issues.apache.org/jira/browse/KAFKA-817 Project: Kafka Issue Type: Bug Components: controller, tools Affects Versions: 0.8.1 Reporter: Joel Koshy Assignee: Neha Narkhede The controlled shutdown tool currently depends on jmxremote.port being exposed. Apparently, this is often not exposed in production environments and makes the script unusable. We can move to a zk-based approach in which the controller watches a path that lists shutting down brokers. This will also make it consistent with the pattern used in some of the other replication-related tools. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KAFKA-808) Migration tool internal queue between consumer and producer threads should be configurable
[ https://issues.apache.org/jira/browse/KAFKA-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-808: Resolution: Fixed Status: Resolved (was: Patch Available) This is checked in Migration tool internal queue between consumer and producer threads should be configurable -- Key: KAFKA-808 URL: https://issues.apache.org/jira/browse/KAFKA-808 Project: Kafka Issue Type: Improvement Components: tools Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Critical Labels: kafka-0.8, p2 Attachments: kafka-808.patch Migration tool maintains an internal blocking queue to buffer messages between the 0.7 consumer and the 0.8 producer. It is fixed in size and it set to the number of producers. However, the consumer usually fetches data in large chunks, several thousands of messages. Also each producer's internal queue frees up in chunks of the producer's batch size. In performance profiling, I saw that the migration tool's consumer thread spent time waiting for space to free up in the internal queue. It seems that this internal queue should be configurable and much larger than the number of producers. This will improve the buffering and help bridge the gap between the consumer and producer's throughput. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (KAFKA-808) Migration tool internal queue between consumer and producer threads should be configurable
[ https://issues.apache.org/jira/browse/KAFKA-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede closed KAFKA-808. --- Migration tool internal queue between consumer and producer threads should be configurable -- Key: KAFKA-808 URL: https://issues.apache.org/jira/browse/KAFKA-808 Project: Kafka Issue Type: Improvement Components: tools Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Critical Labels: kafka-0.8, p2 Attachments: kafka-808.patch Migration tool maintains an internal blocking queue to buffer messages between the 0.7 consumer and the 0.8 producer. It is fixed in size and it set to the number of producers. However, the consumer usually fetches data in large chunks, several thousands of messages. Also each producer's internal queue frees up in chunks of the producer's batch size. In performance profiling, I saw that the migration tool's consumer thread spent time waiting for space to free up in the internal queue. It seems that this internal queue should be configurable and much larger than the number of producers. This will improve the buffering and help bridge the gap between the consumer and producer's throughput. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (KAFKA-890) The list of brokers for fetching metadata should be shuffled
[ https://issues.apache.org/jira/browse/KAFKA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede closed KAFKA-890. --- The list of brokers for fetching metadata should be shuffled - Key: KAFKA-890 URL: https://issues.apache.org/jira/browse/KAFKA-890 Project: Kafka Issue Type: Bug Components: core Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Blocker Labels: kafka-0.8, p1 Attachments: kafka-890.patch The list of brokers in the metadata request is never shuffled. Which means that if some clients are not using a VIP for metadata requests, the first broker ends up servicing most metadata requests, leaving imbalanced load on the brokers. This issue is even more pronounced when there are several thousand clients talking to a cluster each using a broker list to fetch metadata. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KAFKA-892) Change request log to include request completion not handling
[ https://issues.apache.org/jira/browse/KAFKA-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-892: Description: While troubleshooting a lot of 0.8 issues, what I've seen is that often times than not, I've wanted the request processing latency breakdown to be part of the request log. There are of course mbeans to expose this information, but when you are trying to troubleshoot the root cause of few slow requests, this is immensely helpful. Currently, we only include request reception in the request log. We could include both but that would double the size of the request log. So I'm proposing adding just the request completion information in the request log. This will not just tell us which request came into the server, but will also give us a breakdown of where it spent most of its processing time. Change request log to include request completion not handling - Key: KAFKA-892 URL: https://issues.apache.org/jira/browse/KAFKA-892 Project: Kafka Issue Type: Improvement Components: core Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Critical Labels: kafka-0.8 While troubleshooting a lot of 0.8 issues, what I've seen is that often times than not, I've wanted the request processing latency breakdown to be part of the request log. There are of course mbeans to expose this information, but when you are trying to troubleshoot the root cause of few slow requests, this is immensely helpful. Currently, we only include request reception in the request log. We could include both but that would double the size of the request log. So I'm proposing adding just the request completion information in the request log. This will not just tell us which request came into the server, but will also give us a breakdown of where it spent most of its processing time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (KAFKA-886) Update info on Controlled shutdown and Preferred replica election tool
[ https://issues.apache.org/jira/browse/KAFKA-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13646092#comment-13646092 ] Joel Koshy commented on KAFKA-886: -- Thanks for the great write-up. Couple of comments: 1) We should probably add a note on the controlled shutdown tool (script) usage that it is currently JMX-based and depends on the jmx.remote.port property being set (otherwise you won't be be able to use the script and will need to poke jmx through other means). We can reference KAFKA-817 which will remedy this and make it zookeeper-based instead of JMX. 2) Due to the above, in case people need to use local JMX operations and essentially do manually what the script does automatically then it is best to do a controlled shutdown and bounce of the controller last (as otherwise there would be unnecessary controller re-elections). 3) For the ListTopicCommand tool - maybe we should mention that if there are a lot of topics and we list info for all topics it can take a while to run unless it is in the same datacenter as the ZK cluster. Actually I think the ListTopicCommand should really be using the SimpleConsumer or producer to fetch metadata instead of reading ZK directly. That way, people don't have to zip up Kafka and copy it over to their production environment. What do you think? Update info on Controlled shutdown and Preferred replica election tool -- Key: KAFKA-886 URL: https://issues.apache.org/jira/browse/KAFKA-886 Project: Kafka Issue Type: Sub-task Affects Versions: 0.8 Reporter: Sriram Subramanian Assignee: Sriram Subramanian Priority: Blocker Labels: p1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (KAFKA-892) Change request log to include request completion not handling
[ https://issues.apache.org/jira/browse/KAFKA-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KAFKA-892 started by Neha Narkhede. Change request log to include request completion not handling - Key: KAFKA-892 URL: https://issues.apache.org/jira/browse/KAFKA-892 Project: Kafka Issue Type: Improvement Components: core Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Critical Labels: kafka-0.8 Attachments: kafka-892.patch While troubleshooting a lot of 0.8 issues, what I've seen is that often times than not, I've wanted the request processing latency breakdown to be part of the request log. There are of course mbeans to expose this information, but when you are trying to troubleshoot the root cause of few slow requests, this is immensely helpful. Currently, we only include request reception in the request log. We could include both but that would double the size of the request log. So I'm proposing adding just the request completion information in the request log. This will not just tell us which request came into the server, but will also give us a breakdown of where it spent most of its processing time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KAFKA-892) Change request log to include request completion not handling
[ https://issues.apache.org/jira/browse/KAFKA-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-892: Status: Patch Available (was: In Progress) Change request log to include request completion not handling - Key: KAFKA-892 URL: https://issues.apache.org/jira/browse/KAFKA-892 Project: Kafka Issue Type: Improvement Components: core Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Critical Labels: kafka-0.8 Attachments: kafka-892.patch While troubleshooting a lot of 0.8 issues, what I've seen is that often times than not, I've wanted the request processing latency breakdown to be part of the request log. There are of course mbeans to expose this information, but when you are trying to troubleshoot the root cause of few slow requests, this is immensely helpful. Currently, we only include request reception in the request log. We could include both but that would double the size of the request log. So I'm proposing adding just the request completion information in the request log. This will not just tell us which request came into the server, but will also give us a breakdown of where it spent most of its processing time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KAFKA-889) Add mbeans to track socket server's response queue size in addition to request queue size
[ https://issues.apache.org/jira/browse/KAFKA-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-889: Resolution: Fixed Status: Resolved (was: Patch Available) Thanks for the reviews, guys! Add mbeans to track socket server's response queue size in addition to request queue size - Key: KAFKA-889 URL: https://issues.apache.org/jira/browse/KAFKA-889 Project: Kafka Issue Type: Improvement Components: network Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Critical Labels: kafka-0.8 Attachments: kafka-889.patch We only track request queue size of the socket server. However, when response send time is high, it is useful to know the response queue sizes as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (KAFKA-889) Add mbeans to track socket server's response queue size in addition to request queue size
[ https://issues.apache.org/jira/browse/KAFKA-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede closed KAFKA-889. --- Add mbeans to track socket server's response queue size in addition to request queue size - Key: KAFKA-889 URL: https://issues.apache.org/jira/browse/KAFKA-889 Project: Kafka Issue Type: Improvement Components: network Affects Versions: 0.8 Reporter: Neha Narkhede Assignee: Neha Narkhede Priority: Critical Labels: kafka-0.8 Attachments: kafka-889.patch We only track request queue size of the socket server. However, when response send time is high, it is useful to know the response queue sizes as well -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
