[JBoss JIRA] (TEIID-2900) ASSERTION FAILED with UNION
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2900?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2900.
---------------------------------
> ASSERTION FAILED with UNION
> ---------------------------
>
> Key: TEIID-2900
> URL: https://issues.jboss.org/browse/TEIID-2900
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Tom Arnold
> Assignee: Steven Hawkins
> Labels: assertionfailedexception
> Fix For: 8.7
>
> Attachments: TestTranslator.zip
>
>
> This is reproducible in Teiid 8.7 beta2 from the downloads page, and in 8.7 beta3 built from GIT master.
> foo has >1000 rows. bar has 28 rows. Playing with the limit, it's possible to get the query to work.
> {code}
> <model name="foo">
> <source name="foo" translator-name="custom" connection-jndi-name="java:/FooDS"/>
> </model>
> <model name="bar">
> <source name="bar" translator-name="custom" connection-jndi-name="java:/BarDS"/>
> </model>
> {code}
> {code:sql}
> select * from (
> (select identifier from foo.items)
> union all
> (select identifier from bar.items)
> ) x
> order by identifier desc
> limit 1000;
> {code}
> {code}
> 11:15:32,992 DEBUG [org.teiid.COMMAND_LOG] (New I/O worker #1) Nqu3TY8Cd+7P START USER COMMAND: startTime=2014-03-18 11:15:32.992 requestID=Nqu3TY8Cd+7P.0 txID=null sessionID=Nqu3TY8Cd+7P applicationName=JDBCprincipal=user@teiid-security vdbName=Foo vdbVersion=1 sql=select * from (
> (select identifier from foo.items)
> union all
> (select identifier from bar.items)
> ) x
> order by identifier desc
> limit 1000
> 11:15:33,106 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue1) Nqu3TY8Cd+7P START DATA SRC COMMAND: startTime=2014-03-18 11:15:33.106 requestID=Nqu3TY8Cd+7P.0 sourceCommandID=4 executionID=0 txID=null modelName=foo translatorName=foo sessionID=Nqu3TY8Cd+7P principal=user@teiid-security sql=SELECT foo.items.identifier FROM foo.items ORDER BY foo.items.identifier DESC LIMIT 1000
> 11:15:33,106 DEBUG [org.teiid.COMMAND_LOG] (Worker2_QueryProcessorQueue2) Nqu3TY8Cd+7P START DATA SRC COMMAND: startTime=2014-03-18 11:15:33.106 requestID=Nqu3TY8Cd+7P.0 sourceCommandID=6 executionID=1 txID=null modelName=bar translatorName=foo sessionID=Nqu3TY8Cd+7P principal=user@teiid-security sql=SELECT bar.items.identifier FROM bar.items ORDER BY bar.items.identifier DESC LIMIT 1000
> 11:15:33,154 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue3) Nqu3TY8Cd+7P END SRC COMMAND: endTime=2014-03-18 11:15:33.154 requestID=Nqu3TY8Cd+7P.0 sourceCommandID=6 executionID=1 txID=null modelName=bar translatorName=foo sessionID=Nqu3TY8Cd+7P principal=user@teiid-security finalRowCount=28
> 11:15:33,553 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue4) Nqu3TY8Cd+7P END SRC COMMAND: endTime=2014-03-18 11:15:33.553 requestID=Nqu3TY8Cd+7P.0 sourceCommandID=4 executionID=0 txID=null modelName=foo translatorName=foo sessionID=Nqu3TY8Cd+7P principal=user@teiid-security finalRowCount=1000
> 11:15:33,567 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue4) Nqu3TY8Cd+7P ERROR USER COMMAND: endTime=2014-03-18 11:15:33.567 requestID=Nqu3TY8Cd+7P.0 txID=null sessionID=Nqu3TY8Cd+7P principal=user@teiid-security vdbName=Foo vdbVersion=1 finalRowCount=null
> 11:15:33,568 ERROR [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue4) Nqu3TY8Cd+7P TEIID30019 Unexpected exception for request Nqu3TY8Cd+7P.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73) [teiid-common-core-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100) [teiid-common-core-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92) [teiid-common-core-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.common.buffer.TupleBuffer.getBatch(TupleBuffer.java:287) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.common.buffer.TupleBuffer.truncateTo(TupleBuffer.java:425) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.query.processor.relational.SortNode.sortPhase(SortNode.java:117) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.query.processor.relational.SortNode.getBuffer(SortNode.java:205) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.query.processor.relational.LimitNode.getBuffer(LimitNode.java:211) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.query.processor.relational.RelationalPlan.getBuffer(RelationalPlan.java:250) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.query.processor.QueryProcessor.getBuffer(QueryProcessor.java:289) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:149) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:141) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.7.0.Beta2.jar:8.7.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_02]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_02]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_02]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2828) ResteasyEnabler fails with OTHER model types
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2828?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2828.
---------------------------------
> ResteasyEnabler fails with OTHER model types
> --------------------------------------------
>
> Key: TEIID-2828
> URL: https://issues.jboss.org/browse/TEIID-2828
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4.2, 8.7
>
>
> If a vdb contains OTHER type models (typically used for .xsd), then the schema lookup will produce a null and result in an NPE:
> java.lang.NullPointerException
> at org.teiid.jboss.rest.ResteasyEnabler.hasRestMetadata(ResteasyEnabler.java:146) [teiid-jboss-integration-8.4.1-redhat-2.jar:8.4.1-redhat-2]
> at org.teiid.jboss.rest.ResteasyEnabler.finishedDeployment(ResteasyEnabler.java:81) [teiid-jboss-integration-8.4.1-redhat-2.jar:8.4.1-redhat-2]
> at org.teiid.deployers.VDBRepository.notifyFinished(VDBRepository.java:351) [teiid-runtime-8.4.1-redhat-2.jar:8.4.1-redhat-2]
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2833) While importing from Deployed BQT2 VDB, JDBC type of 0 and type name NULL was returned for column with design-time type varbinary
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2833?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2833.
---------------------------------
> While importing from Deployed BQT2 VDB, JDBC type of 0 and type name NULL was returned for column with design-time type varbinary
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2833
> URL: https://issues.jboss.org/browse/TEIID-2833
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.4
> Reporter: Barry LaFond
> Assignee: Steven Hawkins
> Fix For: 8.4.2, 8.7
>
> Attachments: TEIID_2829_project.zip
>
>
> 1) Open attached project in Designer
> 2) Deploy the BQT2.vdb
> 3) Create another project
> 4) Import the VDB metadata via JDBC Importer into your second project (will end up being a read-only VDB source model)
> 5) On *finish* you'll get an exception when processing the type_varbinary column because the type returned is "0" and type name of "null"
> {code}
> java.lang.IllegalArgumentException: Expected argument to be non-null but got null
> at org.teiid.core.designer.util.CoreArgCheck.isNotNull(CoreArgCheck.java:142)
> at org.teiid.core.designer.util.CoreArgCheck.isNotNull(CoreArgCheck.java:128)
> at org.teiid.designer.sdt.types.BuiltInTypesManager.getBuiltInDatatype(BuiltInTypesManager.java:477)
> at org.teiid.designer.sdt.types.WorkspaceDatatypeManager.getBuiltInDatatype(WorkspaceDatatypeManager.java:94)
> at org.teiid.designer.jdbc.relational.impl.RelationalModelProcessorImpl.findType(RelationalModelProcessorImpl.java:1450)
> at org.teiid.designer.jdbc.relational.impl.RelationalModelProcessorImpl.setColumnInfo(RelationalModelProcessorImpl.java:1321)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2358) NullPointer in EnhancedSortMergeJoinStrategy
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2358?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2358.
---------------------------------
> NullPointer in EnhancedSortMergeJoinStrategy
> --------------------------------------------
>
> Key: TEIID-2358
> URL: https://issues.jboss.org/browse/TEIID-2358
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.5
> Reporter: Rakesh Balguri
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.7
>
> Attachments: EnhancedSortMergeJoinStrategyTestCases_Updated.zip
>
>
> java.lang.NullPointerException
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy$SingleTupleSource.get(EnhancedSortMergeJoinStrategy.java:79)
> at org.teiid.query.processor.relational.ListNestedSortComparator.compare(ListNestedSortComparator.java:149)
> at org.teiid.query.processor.relational.ListNestedSortComparator.compare(ListNestedSortComparator.java:59)
> at java.util.Collections.indexedBinarySearch(Collections.java:377)
> at java.util.Collections.binarySearch(Collections.java:365)
> at org.teiid.common.buffer.SPage.search(SPage.java:140)
> at org.teiid.common.buffer.STree.find(STree.java:245)
> at org.teiid.common.buffer.TupleBrowser.setPage(TupleBrowser.java:144)
> at org.teiid.common.buffer.TupleBrowser.nextTuple(TupleBrowser.java:203)
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.process(EnhancedSortMergeJoinStrategy.java:377)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:202)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:70)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:69)
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:82)
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:91)
> at org.teiid.query.processor.relational.MergeJoinStrategy.process(MergeJoinStrategy.java:149)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:202)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.relational.UnionAllNode.nextBatchDirect(UnionAllNode.java:90)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:153)
> at org.teiid.query.processor.relational.SourceState.getTupleBuffer(SourceState.java:174)
> at org.teiid.query.processor.relational.SourceState.getRowCount(SourceState.java:127)
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.shouldIndex(EnhancedSortMergeJoinStrategy.java:306)
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.loadRight(EnhancedSortMergeJoinStrategy.java:253)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:198)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:70)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:69)
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:82)
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:91)
> at org.teiid.query.processor.relational.MergeJoinStrategy.process(MergeJoinStrategy.java:149)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:202)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.relational.UnionAllNode.nextBatchDirect(UnionAllNode.java:90)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.BatchCollector$BatchProducerTupleSource.nextTuple(BatchCollector.java:89)
> at org.teiid.query.processor.relational.GroupingNode.groupPhase(GroupingNode.java:374)
> at org.teiid.query.processor.relational.GroupingNode.nextBatchDirect(GroupingNode.java:318)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:153)
> at org.teiid.query.processor.relational.SourceState.getTupleBuffer(SourceState.java:174)
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.loadLeft(EnhancedSortMergeJoinStrategy.java:229)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:186)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:279)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:148)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:146)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:112)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:153)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:382)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:291)
> ... 8 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2876) Order of DataTypeManager type names affects order of functions in FunctionLibrary
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2876?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2876.
---------------------------------
> Order of DataTypeManager type names affects order of functions in FunctionLibrary
> ---------------------------------------------------------------------------------
>
> Key: TEIID-2876
> URL: https://issues.jboss.org/browse/TEIID-2876
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7, 8.4, 8.7
> Reporter: Paul Richardson
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.7
>
>
> This may be by design but the source code does not document this to be the case and appears brittle and open to future regressions.
> Executing the unit tests in TestFunctionResolving class, 'testResolveCoalesce4', the designer version of the teiid runtime client failed with the following error:
> {code}
> java.lang.AssertionError: expected:<class java.lang.String> but was:<class java.lang.Object>
> {code}
> The unit test passes in Teiid so I needed to determine the reason for the difference. Turns out the difference was the use of a LinkedHashSet rather than a HashSet.
> Tracing this back showed the following:
> # In FunctionLibrary.determineNecessaryConversions, the functionMethods are iterated through. In the case of teiid, the String version of 'coalesce' appears before the Object version and despite both versions of the function being scored the same, the String version is preferred. In the case of designer's runtime client, the Object version appeared before the String version hence the former was chosen and the unit test failed.
> # The functionMethods originate from the FunctionTree and are added into a TreeMap which is only ordered on the function name, ie. coalesce. The typed versions of this function are added to an ArrayList which is not sorted (halfway down addFunction()).
> # The coalesce functions originate from the SystemSource class and are added by iterating over dataTypeManager.getAllDataTypeNames(). Since the latter are in a LinkedHashSet (in teiid) then ordering is preserved and the String datatype happens to precede the Object datatype. In the designer runtime client, this was a HashSet hence the difference in ordering and failing of the test.
> The consequence of this is that determineNecessaryConversions in the FunctionLibrary gets the correct answer for the unit test but seems rather brittle in that a small change to the DataTypeManager's order of DataTypeName additions could have an indirect and non-obvious effect on which typed version of a function is returned by the resolver.
> Suggestions:
> * Ensure that the ArrayLists of functions in the FunctionTree's functionByName map are sorted based upon a narrow to broad ordering of types, ie. Object as the most broad will always be at the end. This will ensure that the scoring in FunctionLibrary.determineNecessaryConversions() will in the event of a tie always pick the narrowest of typed function.
> * Change the scoring in determineNecessaryConversions() to account for 'equal to' as well as 'less than' since String and Object functions get the same score.
> * Document that the ordering of DataTypeManager data type names should not be changed without consideration of this scenario.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months