[JBoss JIRA] (TEIID-5216) JBOSS - Teiid 9.2.1 unable to return DateTimeOffset ODatatype values
by Pushkar Kamra (JIRA)
Pushkar Kamra created TEIID-5216:
------------------------------------
Summary: JBOSS - Teiid 9.2.1 unable to return DateTimeOffset ODatatype values
Key: TEIID-5216
URL: https://issues.jboss.org/browse/TEIID-5216
Project: Teiid
Issue Type: Bug
Components: OData
Affects Versions: 9.2.1
Environment: All
Reporter: Pushkar Kamra
Assignee: Steven Hawkins
During the time of requesting ODatatype - DateTimeOffset from the from the following service - http://services.odata.org/V4/Northwind/Northwind.svc/
Query - Select * from Employees.
Using the above query it is unable to return DateTimeOffset values for it and returns the
following error -
java.lang.IllegalArgumentException: No enum constant org.apache.olingo.commons.api.edm.EdmPrimitiveTypeKind.TimeOffset
at java.lang.Enum.valueOf(Enum.java:238)
at org.apache.olingo.commons.api.edm.EdmPrimitiveTypeKind.valueOf(EdmPrimitiveTypeKind.java:24)
at org.teiid.olingo.common.ODataTypeManager.parseLiteral(ODataTypeManager.java:332)
at org.teiid.olingo.common.ODataTypeManager.convertToTeiidRuntimeType(ODataTypeManager.java:184)
at org.teiid.translator.odata4.BaseQueryExecution.buildRow(BaseQueryExecution.java:244)
at org.teiid.translator.odata4.ODataQueryExecution.next(ODataQueryExecution.java:122)
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:435)
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:238)
at sun.reflect.GeneratedMethodAccessor480.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:220)
at com.sun.proxy.$Proxy398.more(Unknown Source)
at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309)
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:282)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
>From the initial level analysis and observation is has been observed teiid class - ODataTypeManager in that parselitreals method where ODatatype.Substring(4) is done which is causing the issue which is changing DateTimeOffset to TimeOffset and when it tries to find the Enum constant from the EdmPrimitiveTypeKind list it is unable find the changed name and this seems to be causing the issue in accessing the DateTimeOffset type datas from the containing tables.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (TEIID-5212) Additional optimization of left outer joins
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5212?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5212.
-----------------------------------
Fix Version/s: 10.1
Resolution: Done
Updated the outer join planning logic to look for additional associative scenarios that span a left outer join - rather than looking only across a single nested join. The logic is still not entirely general as the left hand structure must be simple (where we can descend to an applicable access node).
> Additional optimization of left outer joins
> -------------------------------------------
>
> Key: TEIID-5212
> URL: https://issues.jboss.org/browse/TEIID-5212
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> Related to TEIID-5016 and TEIID-3652, there are additional circumstances where the join planning logic can combine tables from different parts of a join tree involving left outer joins.
> The referenced forum posting has a star join against ora_ses such that moving the placement of the nested inner join allows for more grouping of the join tables.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (TEIID-5010) Swarm usage should be more configurable
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5010?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5010:
---------------------------------------
[~rareddy] This was logged all the way back with the initial swarm integration when there didn't seem to be a difference in the uber jars being created. If that is now working, then this can be resolved.
> Swarm usage should be more configurable
> ---------------------------------------
>
> Key: TEIID-5010
> URL: https://issues.jboss.org/browse/TEIID-5010
> Project: Teiid
> Issue Type: Sub-task
> Components: WildFly Swarm
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 10.2
>
>
> When building a swarm uber jar the wildfly/swarm functionality remains the same regardless of what is needed. The wildfly fractions/subsystems need to be configurable so that we can drop systems, such as the web server, selectively.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (TEIID-5010) Swarm usage should be more configurable
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5010?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5010:
-------------------------------------
The dependencies defined in the maven build file currently direct what fractions are added to the WF-Swarm uber jar. Are you thinking more than this [~shawkins]?
> Swarm usage should be more configurable
> ---------------------------------------
>
> Key: TEIID-5010
> URL: https://issues.jboss.org/browse/TEIID-5010
> Project: Teiid
> Issue Type: Sub-task
> Components: WildFly Swarm
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 10.2
>
>
> When building a swarm uber jar the wildfly/swarm functionality remains the same regardless of what is needed. The wildfly fractions/subsystems need to be configurable so that we can drop systems, such as the web server, selectively.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (TEIID-5215) Investigate ephemeral disk usage options
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-5215:
-------------------------------------
Summary: Investigate ephemeral disk usage options
Key: TEIID-5215
URL: https://issues.jboss.org/browse/TEIID-5215
Project: Teiid
Issue Type: Sub-task
Components: OpenShift, Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 10.2
We need to give more thought toward our consumption of ephemeral storage - whether that means exposing the buffer disk limit more prominently as a template or other option, or auto-configuring based upon available storage, or something else.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (TEIID-5007) Changes to reduce Teiid in the cloud footprint
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5007?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5007.
-----------------------------------
Resolution: Done
Marking the parent issue as partially resolved for 10.1 and moved the remaining subtasks to 10.2.
> Changes to reduce Teiid in the cloud footprint
> ----------------------------------------------
>
> Key: TEIID-5007
> URL: https://issues.jboss.org/browse/TEIID-5007
> Project: Teiid
> Issue Type: Quality Risk
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> A Teiid instance even as swarm or springboot needs additional considerations to minimize the runtime footprint. This includes:
> * container aware auto-sizing. Detection of the number of cpus and available memory need refined - there are experimental settings being considered for containerized vms to better report these values and there is logic in WildFly and other projects that attempts better auto-detection. We also need to utilize the memory buffer space more and probably as off-heap space (and ideally direct operations on the serialized data)
> * Subsystems required include JTA, webserver, security, which could be satisfied by slimmer alternative versions - especially if we make new assumptions, such as not utilizing xa transactions.
> * Engine dependencies could be application specific - removing xml/xsl support, geometry support, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (TEIID-5136) Osisoft translator - NPE when running query with LATERAL JOIN
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5136?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIID-5136:
-------------------------------------
Assignee: Steven Hawkins (was: Ramesh Reddy)
> Osisoft translator - NPE when running query with LATERAL JOIN
> -------------------------------------------------------------
>
> Key: TEIID-5136
> URL: https://issues.jboss.org/browse/TEIID-5136
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> Running the following query:
> {code:sql}
> SELECT bqt2.smalla.intkey, g2.intkey, bqt2.smalla.bytenum FROM bqt2.smalla LEFT JOIN LATERAL (SELECT intkey FROM bqt2.mediuma WHERE bqt2.smalla.bytenum = bqt2.mediuma.bytenum) AS g2 ON true
> {code}
> results in a NPE in teiid (before sending source src command).
> Stacktrace:
> {noformat}
> Connector worker process failed for atomic-request=vEbs99yd+srV.1.0.1: java.lang.NullPointerException
> at org.teiid.translator.jdbc.pi.PIExecutionFactory.translate(PIExecutionFactory.java:273) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.translator.jdbc.SQLConversionVisitor.append(SQLConversionVisitor.java:111) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.language.visitor.SQLStringVisitor.append(SQLStringVisitor.java:106) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.language.visitor.SQLStringVisitor.visit(SQLStringVisitor.java:767) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.language.Select.acceptVisitor(Select.java:110) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.language.visitor.AbstractLanguageVisitor.visitNode(AbstractLanguageVisitor.java:51) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.language.visitor.SQLStringVisitor.append(SQLStringVisitor.java:91) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.translator.jdbc.SQLConversionVisitor.append(SQLConversionVisitor.java:130) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.translator.jdbc.TranslatedCommand.translateCommand(TranslatedCommand.java:76) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.translator.jdbc.JDBCBaseExecution.translateCommand(JDBCBaseExecution.java:120) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:114) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:363)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_141]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_141]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_141]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy79.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_141]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_141]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_141]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_141]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (TEIID-5136) Osisoft translator - NPE when running query with LATERAL JOIN
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5136?page=com.atlassian.jira.plugin... ]
Work on TEIID-5136 started by Steven Hawkins.
---------------------------------------------
> Osisoft translator - NPE when running query with LATERAL JOIN
> -------------------------------------------------------------
>
> Key: TEIID-5136
> URL: https://issues.jboss.org/browse/TEIID-5136
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> Running the following query:
> {code:sql}
> SELECT bqt2.smalla.intkey, g2.intkey, bqt2.smalla.bytenum FROM bqt2.smalla LEFT JOIN LATERAL (SELECT intkey FROM bqt2.mediuma WHERE bqt2.smalla.bytenum = bqt2.mediuma.bytenum) AS g2 ON true
> {code}
> results in a NPE in teiid (before sending source src command).
> Stacktrace:
> {noformat}
> Connector worker process failed for atomic-request=vEbs99yd+srV.1.0.1: java.lang.NullPointerException
> at org.teiid.translator.jdbc.pi.PIExecutionFactory.translate(PIExecutionFactory.java:273) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.translator.jdbc.SQLConversionVisitor.append(SQLConversionVisitor.java:111) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.language.visitor.SQLStringVisitor.append(SQLStringVisitor.java:106) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.language.visitor.SQLStringVisitor.visit(SQLStringVisitor.java:767) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.language.Select.acceptVisitor(Select.java:110) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.language.visitor.AbstractLanguageVisitor.visitNode(AbstractLanguageVisitor.java:51) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.language.visitor.SQLStringVisitor.append(SQLStringVisitor.java:91) [teiid-api-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.translator.jdbc.SQLConversionVisitor.append(SQLConversionVisitor.java:130) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.translator.jdbc.TranslatedCommand.translateCommand(TranslatedCommand.java:76) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.translator.jdbc.JDBCBaseExecution.translateCommand(JDBCBaseExecution.java:120) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:114) [translator-jdbc-8.12.11.6_4.jar:8.12.11.6_4]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:363)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_141]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_141]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_141]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy79.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_141]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_141]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_141]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_141]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months