[
https://issues.apache.org/jira/browse/CALCITE-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986050#comment-16986050
]
Ruben Q L edited comment on CALCITE-3535 at 12/3/19 12:34 PM:
--------------------------------------------------------------
Based on my previous comments, I committed {{@Ignore}} to
{{UtilTest#testRelBuilderExample}} to see how it impacted CI tests, this is the
result compared to the original PR:
*Original PR*
|Github CI Windows (JDK 8)|stuck|
|Github CI Linux (JDK 11)|stuck|
|Github CI macOS (JDK 13)|stuck|
|AppVeyor (Windows JDK8 & 11)|stuck|
|Travis (Ubuntu JDK 8 & 11)|OK|
*UtilTest#testRelBuilderExample Ignored*
|Github CI Windows (JDK 8)|OK|
|Github CI Linux (JDK 11)|stuck|
|Github CI macOS (JDK 13)|stuck|
|AppVeyor (Windows JDK 8 & 11)|OK|
|Travis (Ubuntu JDK 8 & 11)|OK|
So it seems that the problem is not just UtilTest#testRelBuilderExample? In any
case, the thread dump suggests a deadlock while getting a connection, so maybe
we are dealing with a connection leak in the tests?:
{code}
"Test worker" #12 prio=5 os_prio=0 tid=0x000000001b2c0800 nid=0x16844 waiting
on condition [0x000000001c32b000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000b2047860> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:590)
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:425)
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:346)
at
org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134)
at
org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:809)
at
org.apache.calcite.adapter.jdbc.JdbcSchema.computeTables(JdbcSchema.java:246)
...
at org.apache.calcite.tools.RelBuilder.scan(RelBuilder.java:1069)
at org.apache.calcite.tools.RelBuilder.scan(RelBuilder.java:1095)
at
org.apache.calcite.examples.RelBuilderExample.example1(RelBuilderExample.java:94)
at
org.apache.calcite.examples.RelBuilderExample.doExample(RelBuilderExample.java:61)
at
org.apache.calcite.examples.RelBuilderExample.runAllExamples(RelBuilderExample.java:48)
at
org.apache.calcite.util.UtilTest.testRelBuilderExample(UtilTest.java:1869)
{code}
was (Author: rubenql):
Based on my previous comments, I committed {{@Ignore}} to
{{UtilTest#testRelBuilderExample}} to see how it impacted CI tests, this is the
result compared to the original PR:
*Original PR*
|Github CI Windows (JDK 8)|stuck|
|Github CI Linux (JDK 11)|stuck|
|Github CI macOS (JDK 13)|stuck|
|AppVeyor (Windows JDK8 & 11)|stuck|
|Travis (Ubuntu JDK 8 & 11)|OK|
*UtilTest#testRelBuilderExample Ignored*
|Github CI Windows (JDK 8)|OK|
|Github CI Linux (JDK 11)|stuck|
|Github CI macOS (JDK 13)|stuck|
|AppVeyor (Windows JDK 8 & 11)|OK|
|Travis (Ubuntu JDK 8 & 11)|OK|
So it seems that the problem is not just UtilTest#testRelBuilderExample ?
> EnumerableJoinRule: remove unnecessary Filter on top of INNER Join
> ------------------------------------------------------------------
>
> Key: CALCITE-3535
> URL: https://issues.apache.org/jira/browse/CALCITE-3535
> Project: Calcite
> Issue Type: Task
> Components: core
> Affects Versions: 1.21.0
> Reporter: Ruben Q L
> Assignee: Ruben Q L
> Priority: Minor
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Attachments: threadDump.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With the implementation of CALCITE-2973, now EnumerableHashJoin supports all
> type of conditions (not just equi joins). However, there is still one
> [TODO|https://github.com/apache/calcite/blob/07c1efbb2b42a0e27f9d01968d357d9c1e17cd51/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableJoinRule.java#L89]
> in EnumerableHashJoinRule that, in case of an INNER Join, creates a Filter
> with the non-equi conditions on top of the EnumerableHashJoin (created only
> with the equi-conditions), this filter is not really needed, since now
> EnumerableHashJoinRule can support the full condition: equi and non-equi
> items.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
