[
https://issues.apache.org/jira/browse/KAFKA-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258826#comment-16258826
]
Sönke Liebau commented on KAFKA-6234:
-------------------------------------
Is the 1 second timeout in that relevant to what is being tested, or could we
just try to increase this a little to fix the shaky test? Especially with
stopping and restarting all brokers before that call, there may be some
internal stuff going on that just needs longer than a second to complete.
On the other hand, the waitUntilTrue call is obviously intended to solve this
for a leader not available exception, but this is being interrupted by the
Timeoutexception being thrown in KafkaFutureImpl.get, so this could get
extended to catch this exception as well.
Since the delete request is inside the waitUntilTrue and we probably don't want
to retry the entire delete just because we didn't get a low watermark returned
I think increasing the timeout a bit as a first step is the way to go.
> Transient failure in
> kafka.api.AdminClientIntegrationTest.testLogStartOffsetCheckpoint
> --------------------------------------------------------------------------------------
>
> Key: KAFKA-6234
> URL: https://issues.apache.org/jira/browse/KAFKA-6234
> Project: Kafka
> Issue Type: Bug
> Reporter: Guozhang Wang
>
> Saw this once:
> https://builds.apache.org/job/kafka-pr-jdk9-scala2.12/2669/testReport/junit/kafka.api/AdminClientIntegrationTest/testLogStartOffsetCheckpoint/
> {code}
> Stacktrace
> java.util.concurrent.TimeoutException
> at
> org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:108)
> at
> org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:225)
> at
> kafka.api.AdminClientIntegrationTest.$anonfun$testLogStartOffsetCheckpoint$3(AdminClientIntegrationTest.scala:762)
> at kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:858)
> at
> kafka.api.AdminClientIntegrationTest.testLogStartOffsetCheckpoint(AdminClientIntegrationTest.scala:756)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
