[jira] [Commented] (KAFKA-1630) ConsumerFetcherThread locked in Tomcat
[ https://issues.apache.org/jira/browse/KAFKA-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131388#comment-14131388 ] vijay commented on KAFKA-1630: -- I have configured fetch.size as 500kb which is greater than the largest message size(100KB). Sometimes messages lag over 8000 for a particular topic. Kindly give a solution to solve this problem. ConsumerFetcherThread locked in Tomcat -- Key: KAFKA-1630 URL: https://issues.apache.org/jira/browse/KAFKA-1630 Project: Kafka Issue Type: Bug Components: consumer Affects Versions: 0.8.0 Environment: linux redhat Reporter: vijay Assignee: Neha Narkhede Labels: performance Original Estimate: 12h Remaining Estimate: 12h I am using high level consumer API for consuming messages from kafka. ConsumerFetcherThread gets locked. Kindly look in to the below stack trace ConsumerFetcherThread-SocialTwitterStream6_172.31.240.136-1410398702143-61a247c3-0-1 prio=10 tid=0x7f294001e800 nid=0x1677 runnable [0x7f297aae9000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:215) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked 0x7f2a7c38eb40 (a sun.nio.ch.Util$1) - locked 0x7f2a7c38eb28 (a java.util.Collections$UnmodifiableSet) - locked 0x7f2a7c326f20 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80) at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:193) - locked 0x7f2a7c2163c0 (a java.lang.Object) at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:86) - locked 0x7f2a7c229950 (a sun.nio.ch.SocketAdaptor$SocketInputStream) at java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:200) - locked 0x7f2a7c38ea50 (a java.lang.Object) at kafka.utils.Utils$.read(Utils.scala:395) at kafka.network.BoundedByteBufferReceive.readFrom(BoundedByteBufferReceive.scala:54) at kafka.network.Receive$class.readCompletely(Transmission.scala:56) at kafka.network.BoundedByteBufferReceive.readCompletely(BoundedByteBufferReceive.scala:29) at kafka.network.BlockingChannel.receive(BlockingChannel.scala:100) at kafka.consumer.SimpleConsumer.liftedTree1$1(SimpleConsumer.scala:73) at kafka.consumer.SimpleConsumer.kafka$consumer$SimpleConsumer$$sendRequest(SimpleConsumer.scala:71) - locked 0x7f2a7c38e9f0 (a java.lang.Object) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(SimpleConsumer.scala:110) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1$$anonfun$apply$mcV$sp$1.apply(SimpleConsumer.scala:110) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1$$anonfun$apply$mcV$sp$1.apply(SimpleConsumer.scala:110) at kafka.metrics.KafkaTimer.time(KafkaTimer.scala:33) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1.apply$mcV$sp(SimpleConsumer.scala:109) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1.apply(SimpleConsumer.scala:109) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1.apply(SimpleConsumer.scala:109) at kafka.metrics.KafkaTimer.time(KafkaTimer.scala:33) at kafka.consumer.SimpleConsumer.fetch(SimpleConsumer.scala:108) at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:94) at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:86) at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:51) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1630) ConsumerFetcherThread locked in Tomcat
[ https://issues.apache.org/jira/browse/KAFKA-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131651#comment-14131651 ] Neha Narkhede commented on KAFKA-1630: -- I'm not very clear on what the problem is yet. Are you saying that the consumer stops consuming any messages? Is dead locked ? Could you share the entire thread dump when you think the consumer is dead locked? ConsumerFetcherThread locked in Tomcat -- Key: KAFKA-1630 URL: https://issues.apache.org/jira/browse/KAFKA-1630 Project: Kafka Issue Type: Bug Components: consumer Affects Versions: 0.8.0 Environment: linux redhat Reporter: vijay Assignee: Neha Narkhede Labels: performance Original Estimate: 12h Remaining Estimate: 12h I am using high level consumer API for consuming messages from kafka. ConsumerFetcherThread gets locked. Kindly look in to the below stack trace ConsumerFetcherThread-SocialTwitterStream6_172.31.240.136-1410398702143-61a247c3-0-1 prio=10 tid=0x7f294001e800 nid=0x1677 runnable [0x7f297aae9000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:215) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked 0x7f2a7c38eb40 (a sun.nio.ch.Util$1) - locked 0x7f2a7c38eb28 (a java.util.Collections$UnmodifiableSet) - locked 0x7f2a7c326f20 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80) at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:193) - locked 0x7f2a7c2163c0 (a java.lang.Object) at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:86) - locked 0x7f2a7c229950 (a sun.nio.ch.SocketAdaptor$SocketInputStream) at java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:200) - locked 0x7f2a7c38ea50 (a java.lang.Object) at kafka.utils.Utils$.read(Utils.scala:395) at kafka.network.BoundedByteBufferReceive.readFrom(BoundedByteBufferReceive.scala:54) at kafka.network.Receive$class.readCompletely(Transmission.scala:56) at kafka.network.BoundedByteBufferReceive.readCompletely(BoundedByteBufferReceive.scala:29) at kafka.network.BlockingChannel.receive(BlockingChannel.scala:100) at kafka.consumer.SimpleConsumer.liftedTree1$1(SimpleConsumer.scala:73) at kafka.consumer.SimpleConsumer.kafka$consumer$SimpleConsumer$$sendRequest(SimpleConsumer.scala:71) - locked 0x7f2a7c38e9f0 (a java.lang.Object) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(SimpleConsumer.scala:110) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1$$anonfun$apply$mcV$sp$1.apply(SimpleConsumer.scala:110) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1$$anonfun$apply$mcV$sp$1.apply(SimpleConsumer.scala:110) at kafka.metrics.KafkaTimer.time(KafkaTimer.scala:33) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1.apply$mcV$sp(SimpleConsumer.scala:109) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1.apply(SimpleConsumer.scala:109) at kafka.consumer.SimpleConsumer$$anonfun$fetch$1.apply(SimpleConsumer.scala:109) at kafka.metrics.KafkaTimer.time(KafkaTimer.scala:33) at kafka.consumer.SimpleConsumer.fetch(SimpleConsumer.scala:108) at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:94) at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:86) at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:51) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1493) Use a well-documented LZ4 compression format and remove redundant LZ4HC option
[ https://issues.apache.org/jira/browse/KAFKA-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131758#comment-14131758 ] James Oliver commented on KAFKA-1493: - I have today to work on this, I will see how far I can get. Use a well-documented LZ4 compression format and remove redundant LZ4HC option -- Key: KAFKA-1493 URL: https://issues.apache.org/jira/browse/KAFKA-1493 Project: Kafka Issue Type: Improvement Affects Versions: 0.8.2 Reporter: James Oliver Priority: Blocker Fix For: 0.8.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1590) Binarize trace level request logging along with debug level text logging
[ https://issues.apache.org/jira/browse/KAFKA-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131791#comment-14131791 ] Jay Kreps commented on KAFKA-1590: -- Are we saying that we would only produce a binary log or would this just be an option you could enable? I think for most people they would prefer text logs. The case of max wait = 0 does generate a lot of logging, but people generally don't use that since it generates unbounded load and doesn't improve latency (wait doesn't add latency). Personally I would prefer binary logging was optional. Binarize trace level request logging along with debug level text logging Key: KAFKA-1590 URL: https://issues.apache.org/jira/browse/KAFKA-1590 Project: Kafka Issue Type: Bug Reporter: Guozhang Wang Assignee: Abhishek Sharma Labels: newbie Fix For: 0.9.0 With trace level logging, the request handling logs can grow very fast depending on the client behavior (e.g. consumer with 0 maxWait and hence keep sending fetch requests). Previously we have changed it to debug level which only provides a summary of the requests, omitting request details. However this does not work perfectly since summaries are not sufficient for trouble-shooting, and turning on trace level upon issues will be too late. The proposed solution here, is to default to debug level logging with trace level logging printed as binary format at the same time. The generated binary files can then be further compressed / rolled out. When needed, we will then decompress / parse the trace logs into texts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1369) snappy version update 1.1.x
[
https://issues.apache.org/jira/browse/KAFKA-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132229#comment-14132229
]
Roger Hoover commented on KAFKA-1369:
-
I also ran into this issue on 64-bit Centos 5. The snappy-java maintainer said
that 1.1.1.3 is API compatible with 1.0.5.3 and has libstdc++ statically
compiled into the object file so that it doesn't rely on the OS to have a new
enough version.
https://github.com/xerial/snappy-java/issues/17
snappy version update 1.1.x
---
Key: KAFKA-1369
URL: https://issues.apache.org/jira/browse/KAFKA-1369
Project: Kafka
Issue Type: Bug
Components: core
Affects Versions: 0.8.0, 0.8.1.1
Environment: Red Hat Enterprise Linux Server release 5.8 (Tikanga)
- x64
Reporter: thinker0
Priority: Minor
Attachments: patch.diff
https://github.com/xerial/snappy-java/issues/38 issue
snappy version 1.1.x
{code}
org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] null
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:239)
at org.xerial.snappy.Snappy.clinit(Snappy.java:48)
at
org.xerial.snappy.SnappyInputStream.hasNextChunk(SnappyInputStream.java:351)
at org.xerial.snappy.SnappyInputStream.rawRead(SnappyInputStream.java:159)
at org.xerial.snappy.SnappyInputStream.read(SnappyInputStream.java:142)
at java.io.InputStream.read(InputStream.java:101)
at
kafka.message.ByteBufferMessageSet$$anonfun$decompress$1.apply$mcI$sp(ByteBufferMessageSet.scala:68)
at
kafka.message.ByteBufferMessageSet$$anonfun$decompress$1.apply(ByteBufferMessageSet.scala:68)
at
kafka.message.ByteBufferMessageSet$$anonfun$decompress$1.apply(ByteBufferMessageSet.scala:68)
at scala.collection.immutable.Stream$.continually(Stream.scala:1129)
at
kafka.message.ByteBufferMessageSet$.decompress(ByteBufferMessageSet.scala:68)
at
kafka.message.ByteBufferMessageSet$$anon$1.makeNextOuter(ByteBufferMessageSet.scala:178)
at
kafka.message.ByteBufferMessageSet$$anon$1.makeNext(ByteBufferMessageSet.scala:191)
at
kafka.message.ByteBufferMessageSet$$anon$1.makeNext(ByteBufferMessageSet.scala:145)
at
kafka.utils.IteratorTemplate.maybeComputeNext(IteratorTemplate.scala:66)
at kafka.utils.IteratorTemplate.hasNext(IteratorTemplate.scala:58)
{code}
{code}
/tmp] ldd snappy-1.0.5-libsnappyjava.so
./snappy-1.0.5-libsnappyjava.so: /usr/lib64/libstdc++.so.6: version
`GLIBCXX_3.4.9' not found (required by ./snappy-1.0.5-libsnappyjava.so)
./snappy-1.0.5-libsnappyjava.so: /usr/lib64/libstdc++.so.6: version
`GLIBCXX_3.4.11' not found (required by ./snappy-1.0.5-libsnappyjava.so)
linux-vdso.so.1 = (0x7fff81dfc000)
libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x2b554b43)
libm.so.6 = /lib64/libm.so.6 (0x2b554b731000)
libc.so.6 = /lib64/libc.so.6 (0x2b554b9b4000)
libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x2b554bd0c000)
/lib64/ld-linux-x86-64.so.2 (0x0033e2a0)
{code}
{code}
/tmp] ldd snappy-1.1.1M1-be6ba593-9ac7-488e-953e-ba5fd9530ee1-libsnappyjava.so
ldd: warning: you do not have execution permission for
`./snappy-1.1.1M1-be6ba593-9ac7-488e-953e-ba5fd9530ee1-libsnappyjava.so'
linux-vdso.so.1 = (0x7fff1c132000)
libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x2b9548319000)
libm.so.6 = /lib64/libm.so.6 (0x2b954861a000)
libc.so.6 = /lib64/libc.so.6 (0x2b954889d000)
libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x2b9548bf5000)
/lib64/ld-linux-x86-64.so.2 (0x0033e2a0)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KAFKA-1482) Transient test failures for kafka.admin.DeleteTopicTest
[ https://issues.apache.org/jira/browse/KAFKA-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132302#comment-14132302 ] Jun Rao commented on KAFKA-1482: Sriharsha, Yes, you can take this jira. The failure is transient. So, I am not sure if there is an easy way to reproduce it. Transient test failures for kafka.admin.DeleteTopicTest --- Key: KAFKA-1482 URL: https://issues.apache.org/jira/browse/KAFKA-1482 Project: Kafka Issue Type: Bug Reporter: Guozhang Wang Assignee: Jun Rao Labels: newbie Fix For: 0.8.2 A couple of test cases have timing related transient test failures: kafka.admin.DeleteTopicTest testPartitionReassignmentDuringDeleteTopic FAILED junit.framework.AssertionFailedError: Admin path /admin/delete_topic/test path not deleted even after a replica is restarted at junit.framework.Assert.fail(Assert.java:47) at kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:578) at kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:333) at kafka.admin.DeleteTopicTest.testPartitionReassignmentDuringDeleteTopic(DeleteTopicTest.scala:197) kafka.admin.DeleteTopicTest testDeleteTopicDuringAddPartition FAILED junit.framework.AssertionFailedError: Replica logs not deleted after delete topic is complete at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:338) at kafka.admin.DeleteTopicTest.testDeleteTopicDuringAddPartition(DeleteTopicTest.scala:216) kafka.admin.DeleteTopicTest testRequestHandlingDuringDeleteTopic FAILED org.scalatest.junit.JUnitTestFailedError: fails with exception at org.scalatest.junit.AssertionsForJUnit$class.newAssertionFailedException(AssertionsForJUnit.scala:102) at org.scalatest.junit.JUnit3Suite.newAssertionFailedException(JUnit3Suite.scala:142) at org.scalatest.Assertions$class.fail(Assertions.scala:664) at org.scalatest.junit.JUnit3Suite.fail(JUnit3Suite.scala:142) at kafka.admin.DeleteTopicTest.testRequestHandlingDuringDeleteTopic(DeleteTopicTest.scala:123) Caused by: org.scalatest.junit.JUnitTestFailedError: Test should fail because the topic is being deleted at org.scalatest.junit.AssertionsForJUnit$class.newAssertionFailedException(AssertionsForJUnit.scala:101) at org.scalatest.junit.JUnit3Suite.newAssertionFailedException(JUnit3Suite.scala:142) at org.scalatest.Assertions$class.fail(Assertions.scala:644) at org.scalatest.junit.JUnit3Suite.fail(JUnit3Suite.scala:142) at kafka.admin.DeleteTopicTest.testRequestHandlingDuringDeleteTopic(DeleteTopicTest.scala:120) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KAFKA-1482) Transient test failures for kafka.admin.DeleteTopicTest
[ https://issues.apache.org/jira/browse/KAFKA-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neha Narkhede updated KAFKA-1482: - Assignee: Sriharsha Chintalapani (was: Jun Rao) Transient test failures for kafka.admin.DeleteTopicTest --- Key: KAFKA-1482 URL: https://issues.apache.org/jira/browse/KAFKA-1482 Project: Kafka Issue Type: Bug Reporter: Guozhang Wang Assignee: Sriharsha Chintalapani Labels: newbie Fix For: 0.8.2 A couple of test cases have timing related transient test failures: kafka.admin.DeleteTopicTest testPartitionReassignmentDuringDeleteTopic FAILED junit.framework.AssertionFailedError: Admin path /admin/delete_topic/test path not deleted even after a replica is restarted at junit.framework.Assert.fail(Assert.java:47) at kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:578) at kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:333) at kafka.admin.DeleteTopicTest.testPartitionReassignmentDuringDeleteTopic(DeleteTopicTest.scala:197) kafka.admin.DeleteTopicTest testDeleteTopicDuringAddPartition FAILED junit.framework.AssertionFailedError: Replica logs not deleted after delete topic is complete at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:338) at kafka.admin.DeleteTopicTest.testDeleteTopicDuringAddPartition(DeleteTopicTest.scala:216) kafka.admin.DeleteTopicTest testRequestHandlingDuringDeleteTopic FAILED org.scalatest.junit.JUnitTestFailedError: fails with exception at org.scalatest.junit.AssertionsForJUnit$class.newAssertionFailedException(AssertionsForJUnit.scala:102) at org.scalatest.junit.JUnit3Suite.newAssertionFailedException(JUnit3Suite.scala:142) at org.scalatest.Assertions$class.fail(Assertions.scala:664) at org.scalatest.junit.JUnit3Suite.fail(JUnit3Suite.scala:142) at kafka.admin.DeleteTopicTest.testRequestHandlingDuringDeleteTopic(DeleteTopicTest.scala:123) Caused by: org.scalatest.junit.JUnitTestFailedError: Test should fail because the topic is being deleted at org.scalatest.junit.AssertionsForJUnit$class.newAssertionFailedException(AssertionsForJUnit.scala:101) at org.scalatest.junit.JUnit3Suite.newAssertionFailedException(JUnit3Suite.scala:142) at org.scalatest.Assertions$class.fail(Assertions.scala:644) at org.scalatest.junit.JUnit3Suite.fail(JUnit3Suite.scala:142) at kafka.admin.DeleteTopicTest.testRequestHandlingDuringDeleteTopic(DeleteTopicTest.scala:120) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1482) Transient test failures for kafka.admin.DeleteTopicTest
[ https://issues.apache.org/jira/browse/KAFKA-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132318#comment-14132318 ] Neha Narkhede commented on KAFKA-1482: -- [~sriharsha], Running these test cases with transient failures in a loop with logging turned on might help. Transient test failures for kafka.admin.DeleteTopicTest --- Key: KAFKA-1482 URL: https://issues.apache.org/jira/browse/KAFKA-1482 Project: Kafka Issue Type: Bug Reporter: Guozhang Wang Assignee: Sriharsha Chintalapani Labels: newbie Fix For: 0.8.2 A couple of test cases have timing related transient test failures: kafka.admin.DeleteTopicTest testPartitionReassignmentDuringDeleteTopic FAILED junit.framework.AssertionFailedError: Admin path /admin/delete_topic/test path not deleted even after a replica is restarted at junit.framework.Assert.fail(Assert.java:47) at kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:578) at kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:333) at kafka.admin.DeleteTopicTest.testPartitionReassignmentDuringDeleteTopic(DeleteTopicTest.scala:197) kafka.admin.DeleteTopicTest testDeleteTopicDuringAddPartition FAILED junit.framework.AssertionFailedError: Replica logs not deleted after delete topic is complete at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:338) at kafka.admin.DeleteTopicTest.testDeleteTopicDuringAddPartition(DeleteTopicTest.scala:216) kafka.admin.DeleteTopicTest testRequestHandlingDuringDeleteTopic FAILED org.scalatest.junit.JUnitTestFailedError: fails with exception at org.scalatest.junit.AssertionsForJUnit$class.newAssertionFailedException(AssertionsForJUnit.scala:102) at org.scalatest.junit.JUnit3Suite.newAssertionFailedException(JUnit3Suite.scala:142) at org.scalatest.Assertions$class.fail(Assertions.scala:664) at org.scalatest.junit.JUnit3Suite.fail(JUnit3Suite.scala:142) at kafka.admin.DeleteTopicTest.testRequestHandlingDuringDeleteTopic(DeleteTopicTest.scala:123) Caused by: org.scalatest.junit.JUnitTestFailedError: Test should fail because the topic is being deleted at org.scalatest.junit.AssertionsForJUnit$class.newAssertionFailedException(AssertionsForJUnit.scala:101) at org.scalatest.junit.JUnit3Suite.newAssertionFailedException(JUnit3Suite.scala:142) at org.scalatest.Assertions$class.fail(Assertions.scala:644) at org.scalatest.junit.JUnit3Suite.fail(JUnit3Suite.scala:142) at kafka.admin.DeleteTopicTest.testRequestHandlingDuringDeleteTopic(DeleteTopicTest.scala:120) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1054) Elimiate Compilation Warnings for 0.8 Final Release
[
https://issues.apache.org/jira/browse/KAFKA-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132338#comment-14132338
]
Neha Narkhede commented on KAFKA-1054:
--
[~jriehl], patch looks great. Could you also address the remaining 2 warnings
so we can close the JIRA?
{noformat}
/Users/nnarkhed/Projects/kafka-git-idea/core/src/main/scala/kafka/network/SocketServer.scala:346:
Visited SCOPE_EXIT before visiting corresponding SCOPE_ENTER. SI-6049
try {
^
there were 2 feature warning(s); re-run with -feature for details
two warnings found
:contrib:hadoop-consumer:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note:
/Users/nnarkhed/Projects/kafka-git-idea/contrib/hadoop-consumer/src/main/java/kafka/etl/impl/DataGenerator.java
uses unchecked or unsafe operations.
{noformat}
Elimiate Compilation Warnings for 0.8 Final Release
---
Key: KAFKA-1054
URL: https://issues.apache.org/jira/browse/KAFKA-1054
Project: Kafka
Issue Type: Improvement
Reporter: Guozhang Wang
Labels: newbie
Fix For: 0.9.0
Attachments: KAFKA-1054.patch
Currently we have a total number of 38 warnings for source code compilation
of 0.8.
1) 3 from Unchecked type pattern
2) 6 from Unchecked conversion
3) 29 from Deprecated Hadoop API functions
It's better we finish these before the final release of 0.8
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KAFKA-1482) Transient test failures for kafka.admin.DeleteTopicTest
[ https://issues.apache.org/jira/browse/KAFKA-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132476#comment-14132476 ] Sriharsha Chintalapani commented on KAFKA-1482: --- [~nehanarkhede] I tried the above approach but none of them failed. I tried on centos6 and osx didn't see any issue I'll try on a different platform. Transient test failures for kafka.admin.DeleteTopicTest --- Key: KAFKA-1482 URL: https://issues.apache.org/jira/browse/KAFKA-1482 Project: Kafka Issue Type: Bug Reporter: Guozhang Wang Assignee: Sriharsha Chintalapani Labels: newbie Fix For: 0.8.2 A couple of test cases have timing related transient test failures: kafka.admin.DeleteTopicTest testPartitionReassignmentDuringDeleteTopic FAILED junit.framework.AssertionFailedError: Admin path /admin/delete_topic/test path not deleted even after a replica is restarted at junit.framework.Assert.fail(Assert.java:47) at kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:578) at kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:333) at kafka.admin.DeleteTopicTest.testPartitionReassignmentDuringDeleteTopic(DeleteTopicTest.scala:197) kafka.admin.DeleteTopicTest testDeleteTopicDuringAddPartition FAILED junit.framework.AssertionFailedError: Replica logs not deleted after delete topic is complete at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:338) at kafka.admin.DeleteTopicTest.testDeleteTopicDuringAddPartition(DeleteTopicTest.scala:216) kafka.admin.DeleteTopicTest testRequestHandlingDuringDeleteTopic FAILED org.scalatest.junit.JUnitTestFailedError: fails with exception at org.scalatest.junit.AssertionsForJUnit$class.newAssertionFailedException(AssertionsForJUnit.scala:102) at org.scalatest.junit.JUnit3Suite.newAssertionFailedException(JUnit3Suite.scala:142) at org.scalatest.Assertions$class.fail(Assertions.scala:664) at org.scalatest.junit.JUnit3Suite.fail(JUnit3Suite.scala:142) at kafka.admin.DeleteTopicTest.testRequestHandlingDuringDeleteTopic(DeleteTopicTest.scala:123) Caused by: org.scalatest.junit.JUnitTestFailedError: Test should fail because the topic is being deleted at org.scalatest.junit.AssertionsForJUnit$class.newAssertionFailedException(AssertionsForJUnit.scala:101) at org.scalatest.junit.JUnit3Suite.newAssertionFailedException(JUnit3Suite.scala:142) at org.scalatest.Assertions$class.fail(Assertions.scala:644) at org.scalatest.junit.JUnit3Suite.fail(JUnit3Suite.scala:142) at kafka.admin.DeleteTopicTest.testRequestHandlingDuringDeleteTopic(DeleteTopicTest.scala:120) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
