[JBoss JIRA] (TEIID-2337) Source Hints documenation states source hints can be used in user and transformation queries
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2337?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2337:
---------------------------------------
Were you able to confirm this as an issue?
> Source Hints documenation states source hints can be used in user and transformation queries
> ---------------------------------------------------------------------------------------------
>
> Key: TEIID-2337
> URL: https://issues.jboss.org/browse/TEIID-2337
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Driver, Query Engine
> Affects Versions: 7.7.2, 8.2
> Reporter: Johnathon Lee
> Assignee: Johnathon Lee
>
> Per [1], 15.2.13.4 states that user queries can contain source hints.
> Using hints in transformations as follows [2], I can see the HINT being passed to source. Using a SQL client such as SQuirreL and the Teiid Driver the START USER COMMAND does not show the HINT being passed in.
> [1]
> https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Data_Serv...
> [2]
> I have completed a few steps in order to verify the source hint can be passed along using a test vdb (bqt using SLNTDS08.mw.lab.eng.bos.redhat.com).
> Created a view (SourceView.SMALLA) with the transformation [1a]. Note that there seems to be an issue with designer recognizing the format of the hint in the SQL statement and discarding (which is why the /*+sh:'general hint' has been included). Note that "Source:" is the Source Name specified by the Translator (this can be seen when viewing the vdb in designer).
> Turned up the logging to trace for org.teiid in the logging subsystem [2a].
> Verified via the logging that the hint is being passed to the source system [3a]
> [1a]
> SELECT /*+sh:'general hint' Source:'FIRST_ROWS(10)' */
> *
> FROM
> Source.SmallA
> [2a]
> ...
> <logger category="org.teiid">
> <level name="TRACE"/>
> </logger>
> ...
> [3a]
> 8:54:01,592 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue6) Source-specific command: SELECT /*+ FIRST_ROWS(10) */ g_0.INTKEY FROM SMALLA g_0
> [3]
> 2012-12-31 08:48:20,413 DEBUG [org.teiid.COMMAND_LOG] (New I/O server worker #1-1) START USER COMMAND: startTime=2012-12-31 08:48:20.413 requestID=Rg1eL+X/XzJ3.5 txID=null sessionID=Rg1eL+X/XzJ3 applicationName=JDBC principal=admin@teiid-security vdbName=bqt vdbVersion=1 sql=SELECT
> *
> FROM
> Source.SmallA
--
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, 12 months
[JBoss JIRA] (TEIID-2331) TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
by Mark Addleman (JIRA)
[ https://issues.jboss.org/browse/TEIID-2331?page=com.atlassian.jira.plugin... ]
Mark Addleman commented on TEIID-2331:
--------------------------------------
> Perhaps you're running a patched or pre-release version.
We're definitely running patched 8.1 so that would explain the line numbers. It could take a little effort but we can provide the patched source to get to the actual line numbers.
I believe that we have found the reproducible case. I'll get back to you with details later today.
> TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
> ------------------------------------------------------------------------------------------
>
> Key: TEIID-2331
> URL: https://issues.jboss.org/browse/TEIID-2331
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1
> Environment: Windows 7
> Reporter: Sabina Norderhaug
> Assignee: Steven Hawkins
> Priority: Minor
>
> We are getting this exception during continious execution. Looks like client cancelling the execution
> 16:13:16,171 ERROR [org.teiid.PROCESSOR] (Worker6_QueryProcessorQueue902) TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
> at org.teiid.dqp.internal.process.RequestWorkItem.sendResultsIfNeeded(RequestWorkItem.java:753)
> at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:557)
> at org.teiid.query.processor.BatchCollector.flushBatch(BatchCollector.java:191)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:166)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:382)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:291)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:219)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:249)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:123)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:298)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_03]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
--
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, 12 months
[JBoss JIRA] (TEIID-2331) TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2331?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2331:
---------------------------------------
> The stack trace here appears rooted in Thread.run and, therefore, I wouldn't normally expect to see a "Caused by".
Because of the thread pools nearly all exceptions will be rooted by run. And yes it is possible for exceptions to occur in one thread and be logged by another. However, "Caused by" is due to how the exception bubbles up. I was hoping that there was a higher (possibly lower, but that would be unlikely as someone would have to set the cause on an NPE) exception that better communicated the issue. If the exception really does originate from the RequestWorkItem, then this is an appropriate log - but I can't make sense of the line number. Perhaps you're running a patched or pre-release version.
> We have just identified an NPE in one of our custom functions and I suspect that's the root cause here.
It shouldn't be since we trap exceptions from udfs and rethrow them as processing errors.
> TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
> ------------------------------------------------------------------------------------------
>
> Key: TEIID-2331
> URL: https://issues.jboss.org/browse/TEIID-2331
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1
> Environment: Windows 7
> Reporter: Sabina Norderhaug
> Assignee: Steven Hawkins
> Priority: Minor
>
> We are getting this exception during continious execution. Looks like client cancelling the execution
> 16:13:16,171 ERROR [org.teiid.PROCESSOR] (Worker6_QueryProcessorQueue902) TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
> at org.teiid.dqp.internal.process.RequestWorkItem.sendResultsIfNeeded(RequestWorkItem.java:753)
> at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:557)
> at org.teiid.query.processor.BatchCollector.flushBatch(BatchCollector.java:191)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:166)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:382)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:291)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:219)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:249)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:123)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:298)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_03]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
--
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, 12 months
[JBoss JIRA] (TEIID-2331) TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
by Mark Addleman (JIRA)
[ https://issues.jboss.org/browse/TEIID-2331?page=com.atlassian.jira.plugin... ]
Mark Addleman commented on TEIID-2331:
--------------------------------------
We don't have a reproducible case and it will be a while before we can test on 8.2 We have just identified an NPE in one of our custom functions and I suspect that's the root cause here.
A question about Teiid's exception logging: The stack trace here appears rooted in Thread.run and, therefore, I wouldn't normally expect to see a "Caused by". Is it possible that the exception is generated in another thread and then transferred to this worker thread to be logged?
> TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
> ------------------------------------------------------------------------------------------
>
> Key: TEIID-2331
> URL: https://issues.jboss.org/browse/TEIID-2331
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1
> Environment: Windows 7
> Reporter: Sabina Norderhaug
> Assignee: Steven Hawkins
> Priority: Minor
>
> We are getting this exception during continious execution. Looks like client cancelling the execution
> 16:13:16,171 ERROR [org.teiid.PROCESSOR] (Worker6_QueryProcessorQueue902) TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
> at org.teiid.dqp.internal.process.RequestWorkItem.sendResultsIfNeeded(RequestWorkItem.java:753)
> at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:557)
> at org.teiid.query.processor.BatchCollector.flushBatch(BatchCollector.java:191)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:166)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:382)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:291)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:219)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:249)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:123)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:298)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_03]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
--
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, 12 months
[JBoss JIRA] (TEIID-2331) TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2331?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2331:
---------------------------------------
I don't see a connection to lobs Ramesh, do you see something? In continuous mode lob references should always flow to the client (since its a local client) and shouldn't cause issues on the server side.
I think there should be more to this stacktrace, such as a caused by ... that gives where the NPE is coming from. If I look at 8.2, 8.1, 8.0, the only branch that matches the 753 line number is 8.0, and there that is a log statement that shouldn't produce an NPE and should contain a different log message. Can you reproduce this on 8.2 and/or get more of the log if applicable.
> TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
> ------------------------------------------------------------------------------------------
>
> Key: TEIID-2331
> URL: https://issues.jboss.org/browse/TEIID-2331
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1
> Environment: Windows 7
> Reporter: Sabina Norderhaug
> Assignee: Steven Hawkins
> Priority: Minor
>
> We are getting this exception during continious execution. Looks like client cancelling the execution
> 16:13:16,171 ERROR [org.teiid.PROCESSOR] (Worker6_QueryProcessorQueue902) TEIID30019 Unexpected exception for request kfhsdoaNXYfM.1: java.lang.NullPointerException
> at org.teiid.dqp.internal.process.RequestWorkItem.sendResultsIfNeeded(RequestWorkItem.java:753)
> at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:557)
> at org.teiid.query.processor.BatchCollector.flushBatch(BatchCollector.java:191)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:166)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:382)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:291)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:219)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:249)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:123)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:298)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_03]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
--
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, 12 months
[JBoss JIRA] (TEIID-2338) common table expression performance
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2338:
-------------------------------------
Summary: common table expression performance
Key: TEIID-2338
URL: https://issues.jboss.org/browse/TEIID-2338
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Large common table expressions should be indexed based upon their usage in the query to improve performance.
Also given that we will now back-off of bad dependent joins, we should be more optimistic with using common tables as dependent joins (which would also reduce the need for an index).
--
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, 12 months
[JBoss JIRA] (TEIID-2338) common table expression performance
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2338?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2338:
---------------------------------------
This logic would also be applicable to staging tables in xml planning.
> common table expression performance
> -----------------------------------
>
> Key: TEIID-2338
> URL: https://issues.jboss.org/browse/TEIID-2338
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> Large common table expressions should be indexed based upon their usage in the query to improve performance.
> Also given that we will now back-off of bad dependent joins, we should be more optimistic with using common tables as dependent joins (which would also reduce the need for an index).
--
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, 12 months