[ 
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)

Reply via email to