[JBoss JIRA] (TEIID-2872) Assertion failed error when joining multiple native queries.
by SHI HONG CHIN (JIRA)
[ https://issues.jboss.org/browse/TEIID-2872?page=com.atlassian.jira.plugin... ]
SHI HONG CHIN commented on TEIID-2872:
--------------------------------------
How to know number of tuples? And, what is query plan? I cannot test it in 8.6 because 8.6 consist of another annoying bug that I haven't reported.
> Assertion failed error when joining multiple native queries.
> ------------------------------------------------------------
>
> Key: TEIID-2872
> URL: https://issues.jboss.org/browse/TEIID-2872
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.5
> Environment: Windows 2003 server, Windows 7
> Reporter: SHI HONG CHIN
> Assignee: Steven Hawkins
> Attachments: JakkerData-vdb.xml, sql4.sql
>
>
> If I join multiple native queries, the following error occurred:
> 11:24:16,553 ERROR [org.teiid.PROCESSOR] (Worker21_QueryProcessorQueue534) ePitQkul9Wn5 TEIID30019 Unexpected exception for request ePitQkul9Wn5.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.5.0.Final.jar:8.5.0.Final]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.TupleBuffer.getBatch(TupleBuffer.java:287) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:63) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:257) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:190) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SourceState.sort(SourceState.java:315) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.MergeJoinStrategy.loadRight(MergeJoinStrategy.java:359) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.loadRight(EnhancedSortMergeJoinStrategy.java:257) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:208) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:155) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
--
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, 2 months
[JBoss JIRA] (TEIID-2872) Assertion failed error when joining multiple native queries.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2872?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2872:
---------------------------------------
Still no luck on my end reproducing this. Can you also provide the approximate number of tuples coming from each of the respective native queries is?
> Assertion failed error when joining multiple native queries.
> ------------------------------------------------------------
>
> Key: TEIID-2872
> URL: https://issues.jboss.org/browse/TEIID-2872
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.5
> Environment: Windows 2003 server, Windows 7
> Reporter: SHI HONG CHIN
> Assignee: Steven Hawkins
> Attachments: JakkerData-vdb.xml, sql4.sql
>
>
> If I join multiple native queries, the following error occurred:
> 11:24:16,553 ERROR [org.teiid.PROCESSOR] (Worker21_QueryProcessorQueue534) ePitQkul9Wn5 TEIID30019 Unexpected exception for request ePitQkul9Wn5.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.5.0.Final.jar:8.5.0.Final]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.TupleBuffer.getBatch(TupleBuffer.java:287) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:63) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:257) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:190) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SourceState.sort(SourceState.java:315) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.MergeJoinStrategy.loadRight(MergeJoinStrategy.java:359) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.loadRight(EnhancedSortMergeJoinStrategy.java:257) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:208) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:155) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
--
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, 2 months
[JBoss JIRA] (TEIID-2874) HIVE2: can't get the table list if using other than default database
by Ivan Chan (JIRA)
Ivan Chan created TEIID-2874:
--------------------------------
Summary: HIVE2: can't get the table list if using other than default database
Key: TEIID-2874
URL: https://issues.jboss.org/browse/TEIID-2874
Project: Teiid
Issue Type: Bug
Components: Connector API
Affects Versions: 8.7
Environment: Teiid with Hive2
Reporter: Ivan Chan
Assignee: Steven Hawkins
I am not able to retrieve the table list other than default database.
I have create a database other than default. And I named it as "Testing".
And I put the database name in the URL:
jdbc:hive2://machine_name:port/testing
And it always returns a list of tables from default database. Nothing from "Testing" database
--
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, 2 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2863:
-------------------------------------
> It doesn't get us down to user level configurations, but that would be much more flexible than we have today.
Agree, user level is not possible. Anyway in cases other than simple userid/password I am not even sure how this gets enforced. So, I say we ignore this level for now.
I will start working on elevating the configuration, association with transport and vdb, if we are OK with it. Then we will see we can tackle the single port issue with jdbc.
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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, 2 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2863:
---------------------------------------
> The follow on question is, if the transport is not configured with any SSL certificates how does SSLEngine work, seems like in the code is reading the SSLConfig from transport settings? or does it use anonymous SSL in that case?
If no SSL is configured, the server responds to the client that it's not available. The ODBC client could then be configured to require SSL and hang up.
> Either way, we would need to devise similar functionality for JDBC too, so that we would not need need multiple sockets.
That has been mentioned in the past and requires quite a bit of changes unfortunately - and may present an issue if a client is in mms mode (although I recall logic in Netty that is effectively detecting SSL initialization and reacting appropriately that we could do as well).
> Then, I also propose that we pull the "auth" & "ssl" specific configuration in the transport to Teiid system level with a defined name, then we can just reference it in VDB(s) or Transport(s) as enforcing mechanism. Otherwise all the SSL, auth properties can get little hairy everywhere.
Yes, the SSL would be beneficial to elevate, but does possibly tie into authentication via client certs (which we haven't run into just yet).
> And also VDB does not get commited to one way of doing security, but will depend upon environment (DEV/TEST/PROD) configurations, like we do for data sources.
So I think what you are saying is that transport would just be about port, protocol, sessioning, and worker threads and would specify a default security config. Where a security config would be a named entity specifying SSL details (or a reference to a named ssl config), the security domain, and the authentication type. It doesn't get us down to user level configurations, but that would be much more flexible than we have today.
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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, 2 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2863:
-------------------------------------
Ok, the SSL is over individual connection rather than whole transport. The follow on question is, if the transport is not configured with any SSL certificates how does SSLEngine work, seems like in the code is reading the SSLConfig from transport settings? or does it use anonymous SSL in that case?
Either way, we would need to devise similar functionality for JDBC too, so that we would not need need multiple sockets. Then, I also propose that we pull the "auth" & "ssl" specific configuration in the transport to Teiid system level with a defined name, then we can just reference it in VDB(s) or Transport(s) as enforcing mechanism. Otherwise all the SSL, auth properties can get little hairy everywhere. And also VDB does not get commited to one way of doing security, but will depend upon environment (DEV/TEST/PROD) configurations, like we do for data sources.
Teiid concept of transport is not living up to our original intentions with what users are really looking for -:(
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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, 2 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2863:
---------------------------------------
The Teiid JDBC protocol requires using an SSL socket from the start, if the server is configured for SSL.
For ODBC all connections are over a plain socket and then if the initialization indicates SSL is desired, client/server switch to SSL (an SSLEngine is associated with the socket in PGBackendProtocol).
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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, 2 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2863:
---------------------------------------
In my list I'm talking about possible transport level enhancements to possibly get at better vdb level configuration.
> SSL, right now "is SSL required" is the only flag that comes from client, rest of the configuration comes from transport, don't we do similar functionality when "mms" is present in the JDBC url?
Currently SSL is requested by ODBC clients. I'm saying that we can offer the ability to require SSL (at the transport or vdb level). For JDBC we either require SSL or there is no SSL and this is at the transport level with no ability to configure per vdb.
> Is this a new property? I remember Teiid has functionality some where?
Yes I'm saying that it would be a new property. Again with per vdb configurability.
> I do not think I follow your question about match/map the user names one from other? Do you see any particular need for this?
Based upon the old code I was saying that if the user name was effectively ignored anyway, then couldn't that be used to determine if gss authentication is desired?
If however that user name is going to be used, then it's difficult to go down that path.
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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, 2 months