[JBoss JIRA] (TEIID-3642) RhinoScriptEngineFactory be removed in Java 8
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3642?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3642:
------------------------------------------------
Thomas Hauser <thauser(a)redhat.com> changed the Status of [bug 1254399|https://bugzilla.redhat.com/show_bug.cgi?id=1254399] from NEW to ASSIGNED
> RhinoScriptEngineFactory be removed in Java 8
> ----------------------------------------------
>
> Key: TEIID-3642
> URL: https://issues.jboss.org/browse/TEIID-3642
> Project: Teiid
> Issue Type: Quality Risk
> Components: OData
> Affects Versions: 8.7.1.6_2, 8.12
> Environment: * DV 6.2.0.ER4
> * Java 1.8.0_25
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
>
> RhinoScriptEngineFactory be removed in Java 8, this cause OData war deploy output Error:
> {code}
> 09:30:51,315 WARN [org.jboss.as.dependency.unsupported] (MSC service thread 1-6) JBAS015868: Deployment "deployment.teiid-odata-8.7.1.6_2-redhat-2.war" is using an unsupported module ("org.joda.time:main") which may be changed or removed in future versions without notice.
> 09:30:51,424 ERROR [stderr] (MSC service thread 1-6) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> 09:30:51,429 ERROR [stderr] (MSC service thread 1-1) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> 09:30:51,505 ERROR [stderr] (MSC service thread 1-1) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> 09:30:51,513 ERROR [stderr] (MSC service thread 1-1) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> 09:30:51,583 ERROR [stderr] (MSC service thread 1-1) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> {code}
> *OData war* depend on *org.joda.time*, *org.joda.time* depend on *RhinoScriptEngineFactory*, due to RhinoScriptEngineFactory be removed in Java 8, so stderr output in console.
> h3. how to reproduce
> Start DV 6.2 with Java 8.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3627) Infinispan-dsl-cache translator: comparison operators(GE, LE) problem with string
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3627?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3627:
------------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1254053|https://bugzilla.redhat.com/show_bug.cgi?id=1254053] from NEW to ASSIGNED
> Infinispan-dsl-cache translator: comparison operators(GE,LE) problem with string
> --------------------------------------------------------------------------------
>
> Key: TEIID-3627
> URL: https://issues.jboss.org/browse/TEIID-3627
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12
>
>
> Comparison of string values provides wrong results for GE and LE operators. I provide example queries, notice the number of rows returned by the queries.
> For query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum <= -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}
> LimitNode(0) output=[g_0.stringNum] limit 100
> AccessNode(1) output=[g_0.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum
> {code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum <= '-22' ORDER BY g_0.stringNum{code}
> * result 0 rows
> But for query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum < -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}ProjectNode(0) output=[c.stringNum AS StringNum] [c.stringNum AS StringNum]
> LimitNode(1) output=[c.stringNum] limit 100
> SortNode(2) output=[c.stringNum] [SORT] [c.stringNum]
> SelectNode(3) output=[c.stringNum] c.stringNum < '-22'
> AccessNode(4) output=[c.stringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0{code}
> * result 14 rows
> And query: {code:sql}SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA WHERE BQT1.SmallA.StringNum = -22 ORDER BY StringNum{code}
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.stringNum AS StringNum] limit 100
> AccessNode(1) output=[c.stringNum AS StringNum] SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * SRC CMD: {code:sql}SELECT g_0.stringNum FROM SmallAs.smallARemotecache AS g_0 WHERE g_0.stringNum = '-22' ORDER BY g_0.stringNum{code}
> * result 1 row
> The first query should then return 15 rows instead of 0. Also the queries differ in a way they are processed, the first one is pushed down to infinispan, the other two are processed by teiid, which is probably a regression originally tracked here: TEIID-3424
> The same cause introduces problems with similar queries:
> {code:sql}Select IntKey, StringKey From BQT1.SmallA WHERE NOT(StringKey > 10 AND IntKey < 47) ORDER BY IntKey{code}
> Which is processed as:
> * Process Tree:
> {code:plain}LimitNode(0) output=[c.intKey AS IntKey, c.stringKey AS StringKey] limit 100
> AccessNode(1) output=[c.intKey AS IntKey, c.stringKey AS StringKey] SELECT g_0.intKey, g_0.stringKey FROM SmallAs.smallARemotecache AS g_0 WHERE (g_0.stringKey <= '10') OR (g_0.intKey >= 47) ORDER BY g_0.intKey{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3641) ANSI 89 joins not translating to 92 syntax correctly
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3641?page=com.atlassian.jira.plugin... ]
Work on TEIID-3641 started by Steven Hawkins.
---------------------------------------------
> ANSI 89 joins not translating to 92 syntax correctly
> ----------------------------------------------------
>
> Key: TEIID-3641
> URL: https://issues.jboss.org/browse/TEIID-3641
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.11.2
> Environment: Ubuntu Linux Trusty
> Reporter: Don Krapohl
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> SQL 89 syntax being translated to SQL 92 has the ON portion of the join in the wrong place when there are multiple tables.
> Example source query:
> select sum(Table3.sales) as c1,
> Table1.customer_id as c2,
> Table1.customer_name as c3,
> Table2.store_id as c4
> from
> dim_customer Table1,
> dim_store Table2,
> fact_sales Table3
> where ( Table1.customer_id = Table3.customer_id
> and Table1.customer_id = 3184
> and Table2.store_id = Table3.store_id
> and Table2.store_id = 9020
> and Table3.customer_id = 3184
> and Table3.store_id = 9020 )
> group by Table1.customer_id, Table1.customer_name, Table2.store_id
> is translated to
> SELECT SUM(g_2.sales), g_0.customer_id, g_0.customer_name, g_1.store_id
> FROM dim_customer g_0
> JOIN dim_store g_1
> JOIN fact_sales g_2
> ON g_1.store_id = g_2.store_id
> ON g_0.customer_id = g_2.customer_id
> WHERE g_0.customer_id = 3184
> AND g_1.store_id = 9020
> AND g_2.customer_id = 3184
> AND g_2.store_id = 9020
> GROUP BY g_0.customer_id, g_0.customer_name, g_1.store_id
>
>
>
>
> Notice the two JOIN... JOIN... followed by two ON... ON... statements. Our database (Impala) doesn't recognize this pattern of join syntax. I haven't tested to determine if it's just Impala that doesn't recognize this syntax (implying a translator bug) or core query parsing. Expected query should be something close to:
>
> SELECT SUM(g_2.sales), g_0.customer_id, g_0.customer_name, g_1.store_id
> FROM dim_customer g_0
> JOIN fact_sales g_2
> ON g_0.customer_id = g_2.customer_id
> JOIN dim_store g_1
> ON g_1.store_id = g_2.store_id
> WHERE g_0.customer_id = 3184
> AND g_1.store_id = 9020
> AND g_2.customer_id = 3184
> AND g_2.store_id = 9020
> GROUP BY g_0.customer_id, g_0.customer_name, g_1.store_id
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3637) Query Plan/Execution Plan Enhancements
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3637?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3637:
---------------------------------------
> Van is correct, it still does not show the info we are after.
You'll need to be specific about what you want to see.
> its just that in other DBs you only have to add the word 'explain' before the query, and it will give you the plan.
Unfortunately there's no standard syntax nor plan form. Ours was effectively derived from sql server, so it just depends upon what you are familiar with.
> Query Plan/Execution Plan Enhancements
> --------------------------------------
>
> Key: TEIID-3637
> URL: https://issues.jboss.org/browse/TEIID-3637
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7.1
> Environment: RHEL 6, AWS VM, JBoss EAP (standalone) 6.3.2.GA
> JBoss Data Virtualization 6.1.0.ER4
> Reporter: Jorge Herrera
> Assignee: Steven Hawkins
> Priority: Critical
>
> Query Plan / Execution plan, for any particular query is lacking more explicit information about what the query engine is doing for each query. Would like to know if its JDV doing the processing vs doing push down optimization, and what is the path it takes if its internal to JDV, and also the costs associated with every step.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3643) VDB based kerberos authentication does not work with ODBC
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3643?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3643:
----------------------------------
Fix Version/s: 8.11.3
> VDB based kerberos authentication does not work with ODBC
> ---------------------------------------------------------
>
> Key: TEIID-3643
> URL: https://issues.jboss.org/browse/TEIID-3643
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.12, 8.11.3
>
>
> I have a VDB configured to use GSS authentication. Both, JDBC and ODBC ports are configured to use default "teiid-security" security domain. Accessing the VDB through JDBC works fine, but ODBC throws exception [1], [2]. If the ODBC port is configured to use GSS authentication, connection is successful.
> [1]
> isql -v krb
> [08001][unixODBC]could not connect to server: Spojenie odmietnut
> Is the server running on host "localhost" (::1) and accepting
> TCP/IP connections on port 35432?
> ERROR: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.
> DETAIL: org.teiid.jdbc.TeiidSQLException: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.
> [ISQL]ERROR: Could not SQLConnect
> [2]
> 11:49:56,470 ERROR [org.teiid.ODBC] (New I/O worker #3) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.
> at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:168) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:237) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_40]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_40]
> at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3637) Query Plan/Execution Plan Enhancements
by Jorge Herrera (JIRA)
[ https://issues.jboss.org/browse/TEIID-3637?page=com.atlassian.jira.plugin... ]
Jorge Herrera commented on TEIID-3637:
--------------------------------------
Van is correct, it still does not show the info we are after.
But one thing with that approach of using the NOEXEC ON, is that you have to turn it on and then off when you want to actually execute the query, I know its easy enough, its just that in other DBs you only have to add the word 'explain' before the query, and it will give you the plan.
> Query Plan/Execution Plan Enhancements
> --------------------------------------
>
> Key: TEIID-3637
> URL: https://issues.jboss.org/browse/TEIID-3637
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7.1
> Environment: RHEL 6, AWS VM, JBoss EAP (standalone) 6.3.2.GA
> JBoss Data Virtualization 6.1.0.ER4
> Reporter: Jorge Herrera
> Assignee: Steven Hawkins
> Priority: Critical
>
> Query Plan / Execution plan, for any particular query is lacking more explicit information about what the query engine is doing for each query. Would like to know if its JDV doing the processing vs doing push down optimization, and what is the path it takes if its internal to JDV, and also the costs associated with every step.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (TEIID-3637) Query Plan/Execution Plan Enhancements
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3637?page=com.atlassian.jira.plugin... ]
Van Halbert edited comment on TEIID-3637 at 8/18/15 3:36 PM:
-------------------------------------------------------------
In the database tool, if you execute:
SET NOEXEC ON
before you execute the sql, it won't execute, but will provide a query plan.
But it still doesn't provide the full info you're after.
was (Author: van.halbert):
In the database tool, if you execute:
SET NOEXEC ON
before you execute the sql, it won't execute, but will provide a query plan.
> Query Plan/Execution Plan Enhancements
> --------------------------------------
>
> Key: TEIID-3637
> URL: https://issues.jboss.org/browse/TEIID-3637
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7.1
> Environment: RHEL 6, AWS VM, JBoss EAP (standalone) 6.3.2.GA
> JBoss Data Virtualization 6.1.0.ER4
> Reporter: Jorge Herrera
> Assignee: Steven Hawkins
> Priority: Critical
>
> Query Plan / Execution plan, for any particular query is lacking more explicit information about what the query engine is doing for each query. Would like to know if its JDV doing the processing vs doing push down optimization, and what is the path it takes if its internal to JDV, and also the costs associated with every step.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months