[JBoss JIRA] (TEIID-2795) TTL Snapshot Refresh doesn't fully reload Internal MV if the user query contains LIMIT
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2795?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2795.
---------------------------------
> TTL Snapshot Refresh doesn't fully reload Internal MV if the user query contains LIMIT
> --------------------------------------------------------------------------------------
>
> Key: TEIID-2795
> URL: https://issues.jboss.org/browse/TEIID-2795
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7.8
> Reporter: Debbie Steigner
> Assignee: Johnathon Lee
> Fix For: 7.7.9
>
> Attachments: TEIID-2795.patch
>
>
> using the cache hint to automatically trigger a full snapshot refresh after a specified time to live (TTL)[1]. The TTL works but if the user query that is run contains a LIMIT clause the refresh load uses the LIMIT and doesn't completely load the internal MV and fails load.
> Sequence of events
> 1) Execute the query to initiate the internal MV load
> 2) After caching, issue the same query but with limit of 10,000 to test it is hitting the cache
> 3) Wait for 5 minutes for TTL to expire
> 4) Re-issue the same query with limit of 10,000 and i can see the state change to reloading but once the query has finished fetching 10,000 from data source it terminates and the MV state changed to failed_load. I would have expected the MV to continue to load to rehydrate the cache and the query should be fetching the data from the stale cache. But this is not the case ...
> [1]https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Dat...
--
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
11 years, 11 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 closed TEIID-2872.
---------------------------------
> 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
11 years, 11 months
[JBoss JIRA] (TEIID-2777) java.lang.NoSuchFieldError: ISO8601_WEEK
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2777?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2777.
---------------------------------
> java.lang.NoSuchFieldError: ISO8601_WEEK
> -----------------------------------------
>
> Key: TEIID-2777
> URL: https://issues.jboss.org/browse/TEIID-2777
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 7.7.8
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
>
> Dayofweek function gives the following error:
> Test query is:
> select dayofweek(curdate())
> Server.log:
> 2013-12-11 18:31:48,526 WARN [org.teiid.PROCESSOR] (Worker90_QueryProcessorQueue4724) Processing exception 'Error Code:ERR.015.001.0003 Message:Unable to evaluate dayofweek({d'2013-12-11'}): Error Code:ERR.015.001.0003 Message:Error while evaluating function dayofweek' for request Scc9x1bxXmWr.9. Exception type org.teiid.api.exception.query.ExpressionEvaluationException thrown from org.teiid.query.function.FunctionMethods.dayOfWeek(FunctionMethods.java:398). Enable more detailed logging to see the entire stacktrace.
> 2013-12-11 18:31:48,526 DEBUG [org.teiid.PROCESSOR] (Worker90_QueryProcessorQueue4724) Removing tuplesource for the request Scc9x1bxXmWr.9
> 2013-12-11 18:31:48,526 DEBUG [org.teiid.PROCESSOR] (Worker90_QueryProcessorQueue4724) Sending error to client Scc9x1bxXmWr.9
> org.teiid.api.exception.query.ExpressionEvaluationException: Error Code:ERR.015.001.0003 Message:Unable to evaluate dayofweek({d'2013-12-11'}): Error Code:ERR.015.001.0003 Message:Error while evaluating function dayofweek
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:658)
> at org.teiid.query.rewriter.QueryRewriter.evaluate(QueryRewriter.java:2168)
> at org.teiid.query.rewriter.QueryRewriter.rewriteExpressionDirect(QueryRewriter.java:2162)
> at org.teiid.query.rewriter.QueryRewriter.access$000(QueryRewriter.java:97)
> at org.teiid.query.rewriter.QueryRewriter$3.replaceExpression(QueryRewriter.java:723)
> at org.teiid.query.sql.visitor.ExpressionMappingVisitor.visit(ExpressionMappingVisitor.java:194)
> at org.teiid.query.sql.symbol.ExpressionSymbol.acceptVisitor(ExpressionSymbol.java:82)
> at org.teiid.query.sql.navigator.AbstractNavigator.visitVisitor(AbstractNavigator.java:52)
> at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.postVisitVisitor(PreOrPostOrderNavigator.java:140)
> at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.visit(PreOrPostOrderNavigator.java:261)
> at org.teiid.query.sql.symbol.ExpressionSymbol.acceptVisitor(ExpressionSymbol.java:82)
> at org.teiid.query.sql.navigator.AbstractNavigator.visitNode(AbstractNavigator.java:61)
> at org.teiid.query.sql.navigator.AbstractNavigator.visitNodes(AbstractNavigator.java:72)
> at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.visit(PreOrPostOrderNavigator.java:425)
> at org.teiid.query.sql.lang.Select.acceptVisitor(Select.java:168)
> at org.teiid.query.sql.navigator.PostOrderNavigator.doVisit(PostOrderNavigator.java:40)
> at org.teiid.query.rewriter.QueryRewriter.rewriteExpressions(QueryRewriter.java:730)
> at org.teiid.query.rewriter.QueryRewriter.rewriteQuery(QueryRewriter.java:577)
> at org.teiid.query.rewriter.QueryRewriter.rewriteCommand(QueryRewriter.java:196)
> at org.teiid.query.rewriter.QueryRewriter.evaluateAndRewrite(QueryRewriter.java:147)
> at org.teiid.query.processor.relational.AccessNode.rewriteAndEvaluate(AccessNode.java:231)
> at org.teiid.query.processor.relational.AccessNode.prepareNextCommand(AccessNode.java:252)
> at org.teiid.query.processor.relational.AccessNode.open(AccessNode.java:144)
> at org.teiid.query.processor.relational.RelationalPlan.open(RelationalPlan.java:140)
> at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:182)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:126)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:105)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:151)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:133)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:377)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:290)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:218)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:244)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:122)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:292)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.teiid.api.exception.query.FunctionExecutionException: Error Code:ERR.015.001.0003 Message:Error while evaluating function dayofweek
> at org.teiid.query.function.FunctionDescriptor.invokeFunction(FunctionDescriptor.java:201)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:1070)
> at org.teiid.query.eval.Evaluator.internalEvaluate(Evaluator.java:686)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:656)
> ... 38 more
> Caused by: java.lang.NoSuchFieldError: ISO8601_WEEK
> at org.teiid.query.function.FunctionMethods.dayOfWeek(FunctionMethods.java:398)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.teiid.query.function.FunctionDescriptor.invokeFunction(FunctionDescriptor.java:196)
> ... 41 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
11 years, 11 months
[JBoss JIRA] (TEIID-994) Unable to execute Oracle pipelined table function as procedure
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-994?page=com.atlassian.jira.plugin.... ]
Steven Hawkins commented on TEIID-994:
--------------------------------------
Can we get the actual customer scenarios for this to verify that the above solutions will work?
> Unable to execute Oracle pipelined table function as procedure
> --------------------------------------------------------------
>
> Key: TEIID-994
> URL: https://issues.jboss.org/browse/TEIID-994
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.7.1, Open To Community
>
>
> Oracle pipelined table functions (can be used in Oracle queries as TABLE(...)) that can be put in the FROM clause and used as if they were tables although they are really procedures. We found that we imported this table function, although didn't get it quite right - the result set was wrong, which may just be a deficiency of the JDBC import metadata. We were able to map the proc to a table and execute but when we did we got a PL/SQL error from the db.
> Because this is a proc, we are executing it as a CallableStatement down in the JDBC connector which apparently does not work with DataDirect. I'm not sure how we can detect and do something different but seems like we need to have some metadata (procedure name in source?) that can tell us that this proc needs to be run differently and have the Oracle JDBC Connector deal with this properly.
--
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
11 years, 11 months
[JBoss JIRA] (TEIID-2912) Teiid JDBC-ODBC bridge metada import fails from MS Access 2013
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2912?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2912.
-----------------------------------
Fix Version/s: 8.8
Resolution: Done
Updated the AccessExectionFactory with default import parameters - which can be overriden if the users chooses. If the simple jdbc translator is used, the user must manually enter the overrides. Moving forward we'll want people to switch to another JDBC library for Access (there look to be a couple of open source alternatives), so it's not quite clear if they will have the same limitations. We may have to revisit these defaults later then.
> Teiid JDBC-ODBC bridge metada import fails from MS Access 2013
> --------------------------------------------------------------
>
> Key: TEIID-2912
> URL: https://issues.jboss.org/browse/TEIID-2912
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.4
> Reporter: Filip Nguyen
> Fix For: 8.7.1, 8.8
>
> Attachments: server-importKeysFalse.log, server.log, standalone.xml, test-vdb.xml
>
>
> Environment:
> * MS Access 2013
> * Windows 2012 Server
> VDB:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="testVDB" version="1">
> <description>Importer VDB</description>
> <property name="UseConnectorMetadata" value="true" />
> <model name="testAccessModel" type="PHYSICAL" visible="true">
> <source name="testAccessModel" translator-name="jdbc-simple" connection-jndi-name="java:/AccessDS" />
> </model>
> </vdb>
> {code}
> Log exceprt (full log attached):
> {noformat}
> ory] (teiid-async-threads - 4) Driver loaded and instance created:sun.jdbc.odbc.JdbcOdbcDriver@49dd4a28
> 08:32:23,935 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 4) JDBCMetadataProcessor - Importing tables
> 08:32:23,952 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 4) JDBCMetadataProcessor - Importing columns
> 08:32:23,985 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 4) JDBCMetadataProcessor - Importing primary keys
> 08:32:23,985 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (teiid-async-threads - 4) AccessDS: returnConnection(2677c1e5, false) [1/20]
> 08:32:23,985 WARN [org.teiid.RUNTIME] (teiid-async-threads - 4) TEIID50036 VDB testVDB.1 model "testAccessModel" metadata failed to load. Reason:TEIID11010 java.sql.SQLException: [Microsoft][ODBC Driver Manager] Driver does not support this function
> {noformat}
> Driver (standalone.xml attached):
> {code:xml}
> <datasource jndi-name="java:/AccessDS" pool-name="AccessDS" enabled="true">
> <connection-url>jdbc:odbc:AccessDS</connection-url>
> <driver>odbc</driver>
> <transaction-isolation>TRANSACTION_NONE</transaction-isolation>
> <pool>
> <prefill>false</prefill>
> <use-strict-min>false</use-strict-min>
> <flush-strategy>FailingConnectionOnly</flush-strategy>
> </pool>
> </datasource>
> ...
> <drivers>
> <driver name="odbc" module="sun.jdk">
> <driver-class>sun.jdbc.odbc.JdbcOdbcDriver</driver-class>
> </driver>
> </drivers>
> {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
11 years, 11 months
[JBoss JIRA] (TEIID-2885) Allow dependent join pushdown to be chosen by the planner
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2885?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2885.
-----------------------------------
Fix Version/s: 8.8
Resolution: Done
Allowed the planner to utilize a pushdown dependent join even if a hint is not specified. If there is a hint (without a join directive) with a max, then we still won't pushdown as we will try to honor the max using a standard dependent join.
Introduced two system properties documented in the admin guide:
org.teiid.defaultIndependentCardinality - defaults to 10. The number of independent rows or less that can automatically trigger a dependent join. Increase when tables typically only have cardinality set and more dependent joins are desired.
This was introduced to make the value less "magically" - it was also introduced in the MMX days and has not been updated since.
org.teiid.dependentJoinPushdownThreshold - defaults to 0. The data width ratio of all pushdown columns to just the equi-join columns that will be considered for a full dependent join pushdown without a hint. A setting less than 1 effectively disables allowing the optimizer to choose to fully push a dependent join. A setting of 1 will only enable full pushdown of joins that only require the use the equi-join columns. And a setting greater than 1 will allow wider data sets to be considered.
dependentJoinPushdownThreshold provides one dimension of control as to whether the join should be pushed down. Ideally we would consider the plan both ways, but the act of speculatively raising the access node is somewhat destructive. So without a lot of additional logic, we'll make this simple check for now. Additional engine logic and the ability to defer to the translator is expected.
> Allow dependent join pushdown to be chosen by the planner
> ---------------------------------------------------------
>
> Key: TEIID-2885
> URL: https://issues.jboss.org/browse/TEIID-2885
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.7.1, 8.8
>
>
> As a follow on to TEIID-2249, the planner should be able to choose when to use full join pushdown, rather than only relying upon a hint. One downside to this currently is that there isn't a good way to do a back off to a different join processing (unless we embedded an alternative plan) and so we may have to add failure logic if too many independent values are retrieved.
--
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
11 years, 11 months