[JBoss JIRA] (TEIID-4152) Error: ASSERTION FAILED: expected reference to be not null
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4152?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4152:
---------------------------------------
I've had no success trying to reproduce this. I can create a structurally similar plan and hit the same code path as the stacktrace, but I can't quite get the exception. If you have any more that you can provide here, such as the row counts of the queries involved and if this is still occurring on a later Teiid that would be helpful.
> Error: ASSERTION FAILED: expected reference to be not null
> ----------------------------------------------------------
>
> Key: TEIID-4152
> URL: https://issues.jboss.org/browse/TEIID-4152
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.11.3
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Attachments: queryplan.txt
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-4175) Certain nested dependent join structure will cause fewer results than expected
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4175?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4175:
----------------------------------
Description:
With a query such as:
{code}
SELECT pm1.g1.e1, pm1.g2.e2 from /*+ makeind */ pm1.g1 inner join /*+ preserve */ (/*+ makeind */ pm1.g2 inner join pm1.g3 on pm1.g2.e2 = pm1.g3.e2) on pm1.g1.e1 = pm1.g2.e1
{code}
There will be a join structure like:
{code}
JoinNode(1) [Dependent]
AccessNode(2)
JoinNode(3) [Dependent] [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)]
DependentAccessNode(4)
DependentAccessNode(5)
{code}
Such that there is a dependent join as a left child of a merge join that is marked as having that child already sorted. When there is more than 1 query needed for DependentAccessNode(4), the DependentAccessNode will mistakenly mark the right child as needing to be sorted.
was:
With a query such as:
SELECT pm1.g1.e1, pm1.g2.e2 from /*+ makeind */ pm1.g1 inner join /*+ preserve */ (/*+ makeind */ pm1.g2 inner join pm1.g3 on pm1.g2.e2 = pm1.g3.e2) on pm1.g1.e1 = pm1.g2.e1
There will be a join structure like:
JoinNode(1) [Dependent]
AccessNode(2)
JoinNode(3) [Dependent] [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)]
DependentAccessNode(4)
DependentAccessNode(5)
Such that there is a dependent join as a left child of a merge join that is marked as having that child already sorted. When there is more than 1 query needed for DependentAccessNode(4), the DependentAccessNode will mistakenly mark the right child as needing to be sorted.
> Certain nested dependent join structure will cause fewer results than expected
> ------------------------------------------------------------------------------
>
> Key: TEIID-4175
> URL: https://issues.jboss.org/browse/TEIID-4175
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 9.0, 8.12.5, 8.13.5
>
>
> With a query such as:
> {code}
> SELECT pm1.g1.e1, pm1.g2.e2 from /*+ makeind */ pm1.g1 inner join /*+ preserve */ (/*+ makeind */ pm1.g2 inner join pm1.g3 on pm1.g2.e2 = pm1.g3.e2) on pm1.g1.e1 = pm1.g2.e1
> {code}
> There will be a join structure like:
> {code}
> JoinNode(1) [Dependent]
> AccessNode(2)
> JoinNode(3) [Dependent] [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)]
> DependentAccessNode(4)
> DependentAccessNode(5)
> {code}
> Such that there is a dependent join as a left child of a merge join that is marked as having that child already sorted. When there is more than 1 query needed for DependentAccessNode(4), the DependentAccessNode will mistakenly mark the right child as needing to be sorted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-4175) Certain nested dependent join structure will cause fewer results than expected
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4175:
-------------------------------------
Summary: Certain nested dependent join structure will cause fewer results than expected
Key: TEIID-4175
URL: https://issues.jboss.org/browse/TEIID-4175
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Blocker
Fix For: 9.0, 8.12.5, 8.13.5
With a query such as:
SELECT pm1.g1.e1, pm1.g2.e2 from /*+ makeind */ pm1.g1 inner join /*+ preserve */ (/*+ makeind */ pm1.g2 inner join pm1.g3 on pm1.g2.e2 = pm1.g3.e2) on pm1.g1.e1 = pm1.g2.e1
There will be a join structure like:
JoinNode(1) [Dependent]
AccessNode(2)
JoinNode(3) [Dependent] [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)]
DependentAccessNode(4)
DependentAccessNode(5)
Such that there is a dependent join as a left child of a merge join that is marked as having that child already sorted. When there is more than 1 query needed for DependentAccessNode(4), the DependentAccessNode will mistakenly mark the right child as needing to be sorted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-3557) Can't reload VDB in domain mode
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3557?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3557:
-------------------------------------
Yeah, I have only one system, I am running in domain mode, which invokes two different servers. I need to barrow another machine before I can try two individual nodes.
> Can't reload VDB in domain mode
> -------------------------------
>
> Key: TEIID-3557
> URL: https://issues.jboss.org/browse/TEIID-3557
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: 8.7.1.6_2, 8.12, 8.11.1
>
>
> Can't reload VDB in domain mode, get the following error:
> Server throws the following exception:
> [Server:server-one] 12:26:45,678 ERROR [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID40088 Could not replicate object org.teiid.query.tempdata.GlobalTableStoreImpl@4e6c9a30: java.lang.IllegalStateException: cluster 'ModeShape.1' is already connected to singleton transport: [dummy-1435055090515, loopback.1, ModeShape.1, loopback-dynamic.1, $TEIID_BM$, dummy-1435055090188, dummy-1435055205654, $TEIID_ED$, teiid-cache, ddl2-vdb.1]
> [Server:server-one] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:919) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.startStack(JChannel.java:827) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel._preConnect(JChannel.java:525) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.connect(JChannel.java:268) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.teiid.replication.jgroups.JGroupsObjectReplicator.replicate(JGroupsObjectReplicator.java:563) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.CompositeGlobalTableStore.createInstance(CompositeGlobalTableStore.java:57) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$1.finishedDeployment(VDBService.java:156) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.VDBRepository.notifyFinished(VDBRepository.java:352) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.VDBRepository.finishDeployment(VDBRepository.java:308) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.runtime.AbstractVDBDeployer.metadataLoaded(AbstractVDBDeployer.java:202) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService.access$1100(VDBService.java:85) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$6.run(VDBService.java:411) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:server-one] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> VDB reload works fine in standalone mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-3557) Can't reload VDB in domain mode
by Steve Tran (JIRA)
[ https://issues.jboss.org/browse/TEIID-3557?page=com.atlassian.jira.plugin... ]
Steve Tran commented on TEIID-3557:
-----------------------------------
You have at least 2 servers right? What's your test environment look like? I'm afraid if it's all localhost based, the problem may not manifest itself.
> Can't reload VDB in domain mode
> -------------------------------
>
> Key: TEIID-3557
> URL: https://issues.jboss.org/browse/TEIID-3557
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: 8.7.1.6_2, 8.12, 8.11.1
>
>
> Can't reload VDB in domain mode, get the following error:
> Server throws the following exception:
> [Server:server-one] 12:26:45,678 ERROR [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID40088 Could not replicate object org.teiid.query.tempdata.GlobalTableStoreImpl@4e6c9a30: java.lang.IllegalStateException: cluster 'ModeShape.1' is already connected to singleton transport: [dummy-1435055090515, loopback.1, ModeShape.1, loopback-dynamic.1, $TEIID_BM$, dummy-1435055090188, dummy-1435055205654, $TEIID_ED$, teiid-cache, ddl2-vdb.1]
> [Server:server-one] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:919) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.startStack(JChannel.java:827) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel._preConnect(JChannel.java:525) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.connect(JChannel.java:268) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.teiid.replication.jgroups.JGroupsObjectReplicator.replicate(JGroupsObjectReplicator.java:563) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.CompositeGlobalTableStore.createInstance(CompositeGlobalTableStore.java:57) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$1.finishedDeployment(VDBService.java:156) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.VDBRepository.notifyFinished(VDBRepository.java:352) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.VDBRepository.finishDeployment(VDBRepository.java:308) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.runtime.AbstractVDBDeployer.metadataLoaded(AbstractVDBDeployer.java:202) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService.access$1100(VDBService.java:85) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$6.run(VDBService.java:411) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:server-one] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> VDB reload works fine in standalone mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-3557) Can't reload VDB in domain mode
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3557?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3557:
-------------------------------------
can not seemed to duplicate the error with my environment with updated settings either. :(
> Can't reload VDB in domain mode
> -------------------------------
>
> Key: TEIID-3557
> URL: https://issues.jboss.org/browse/TEIID-3557
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: 8.7.1.6_2, 8.12, 8.11.1
>
>
> Can't reload VDB in domain mode, get the following error:
> Server throws the following exception:
> [Server:server-one] 12:26:45,678 ERROR [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID40088 Could not replicate object org.teiid.query.tempdata.GlobalTableStoreImpl@4e6c9a30: java.lang.IllegalStateException: cluster 'ModeShape.1' is already connected to singleton transport: [dummy-1435055090515, loopback.1, ModeShape.1, loopback-dynamic.1, $TEIID_BM$, dummy-1435055090188, dummy-1435055205654, $TEIID_ED$, teiid-cache, ddl2-vdb.1]
> [Server:server-one] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:919) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.startStack(JChannel.java:827) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel._preConnect(JChannel.java:525) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.connect(JChannel.java:268) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.teiid.replication.jgroups.JGroupsObjectReplicator.replicate(JGroupsObjectReplicator.java:563) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.CompositeGlobalTableStore.createInstance(CompositeGlobalTableStore.java:57) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$1.finishedDeployment(VDBService.java:156) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.VDBRepository.notifyFinished(VDBRepository.java:352) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.VDBRepository.finishDeployment(VDBRepository.java:308) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.runtime.AbstractVDBDeployer.metadataLoaded(AbstractVDBDeployer.java:202) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService.access$1100(VDBService.java:85) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$6.run(VDBService.java:411) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:server-one] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> VDB reload works fine in standalone mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years