[
https://issues.apache.org/jira/browse/DRILL-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383377#comment-14383377
]
Daniel Barclay (Drill) commented on DRILL-2579:
-----------------------------------------------
The core problem is that a testing utility accidentally re-used a closed
connection rather than opening a new one.
(Upon JUnit's detection of the test failure, the utility closed the
connection, but didn't null out a pointer to that connection, which caused the
closed connection got re-used.
Drill's JDBC methods don't yet check whether the associated Connection,
Statement, or ResultSet (etc.) is closed and, if it is, throw a SQLException
(DRILL-2489), so the re-use of the closed connection didn't get detected
explicitly.)
> JDBC unit tests will timeout after one testcase failed with unexpected
> results.
> ---------------------------------------------------------------------------------
>
> Key: DRILL-2579
> URL: https://issues.apache.org/jira/browse/DRILL-2579
> Project: Apache Drill
> Issue Type: Bug
> Components: Tools, Build & Test
> Reporter: Jinfeng Ni
> Assignee: Daniel Barclay (Drill)
>
> In unit testcase such as TestJdbcQuery, if there is one failing unit testcase
> due to unexpected results, then the rest of unit test cases will hit timeout
> issue. See following stack trace:
> {code}
> java.lang.Exception: test timed out after 40000 milliseconds
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.apache.drill.jdbc.DrillResultSet.execute(DrillResultSet.java:109)
> at org.apache.drill.jdbc.DrillResultSet.execute(DrillResultSet.java:49)
> at
> net.hydromatic.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:404)
> at
> net.hydromatic.avatica.AvaticaStatement.executeQueryInternal(AvaticaStatement.java:351)
> at
> net.hydromatic.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:78)
> at
> org.apache.drill.jdbc.test.JdbcAssert$TestDataConnection.returns(JdbcAssert.java:203)
> at
> org.apache.drill.jdbc.test.TestJdbcQuery.testCaseWith2ThensAndElse(TestJdbcQuery.java:302)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 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$StatementThread.run(FailOnTimeout.java:74)
> {code}
> To re-produce this issue, simply intentionally modify the expected results
> for one originally successful unit testcase in TestJdbcQuery.java to make it
> fail with unexpected results. You will see the rest of unit test cases start
> timeout, after the failure.
> Possible cause of this issue : the count down latch is not released, if the
> testcase is failling due to unexpected results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
