May 2017 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4919) Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4919?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4919: --------------------------------------- Not directly - the issue is that the query in the Sybase driver method com.sybase.jdbc4.jdbc.SybDatabaseMetaData.getColumns must need to create a temp table in the 'tempdb' database. > Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: TEIID-4919 > URL: https://issues.jboss.org/browse/TEIID-4919 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 9.1.1 > Reporter: Ivan Chan > Assignee: Steven Hawkins > > When I try to build VDB with sybase ASE 15.7 odb schema, I run into the following error: > Caused by: java.sql.SQLException: The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database. > at com.sybase.jdbc4.jdbc.SybConnection.getAllExceptions(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.handleSQLE(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.queryLoop(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.executeQuery(Unknown Source) > at com.sybase.jdbc4.jdbc.SybCallableStatement.executeQuery(Unknown Source) > at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.if(Unknown Source) > at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.getColumns(Unknown Source) > at org.apache.commons.dbcp.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:218) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getColumns(JDBCMetdataProcessor.java:382) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getTables(JDBCMetdataProcessor.java:334) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:173) > at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:306) > ... 182 more > I am using this driver: jconn4.jar [ com.sybase.jdbc4.jdbc.SybDriver ] > And org.teiid.translator.jdbc.sybase.SybaseExecutionFactor -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4919) Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.

by Ivan Chan (JIRA)

[ https://issues.jboss.org/browse/TEIID-4919?page=com.atlassian.jira.plugin... ] Ivan Chan commented on TEIID-4919: ---------------------------------- Is Teiid trying to use any of these commands in order to retrieve metadata? http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc31654_125... > Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: TEIID-4919 > URL: https://issues.jboss.org/browse/TEIID-4919 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 9.1.1 > Reporter: Ivan Chan > Assignee: Steven Hawkins > > When I try to build VDB with sybase ASE 15.7 odb schema, I run into the following error: > Caused by: java.sql.SQLException: The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database. > at com.sybase.jdbc4.jdbc.SybConnection.getAllExceptions(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.handleSQLE(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.queryLoop(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.executeQuery(Unknown Source) > at com.sybase.jdbc4.jdbc.SybCallableStatement.executeQuery(Unknown Source) > at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.if(Unknown Source) > at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.getColumns(Unknown Source) > at org.apache.commons.dbcp.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:218) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getColumns(JDBCMetdataProcessor.java:382) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getTables(JDBCMetdataProcessor.java:334) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:173) > at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:306) > ... 182 more > I am using this driver: jconn4.jar [ com.sybase.jdbc4.jdbc.SybDriver ] > And org.teiid.translator.jdbc.sybase.SybaseExecutionFactor -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4884) Google spreadsheet throws Error when getting batch 401:Unauthorized

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4884?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4884: ---------------------------------- Fix Version/s: 10.0 9.3.1 (was: 9.3) > Google spreadsheet throws Error when getting batch 401:Unauthorized > ------------------------------------------------------------------- > > Key: TEIID-4884 > URL: https://issues.jboss.org/browse/TEIID-4884 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 9.3 > Reporter: Lucie Fabrikova > Assignee: Steven Hawkins > Fix For: 10.0, 9.3.1 > > Attachments: gs-http401 > > > It seems that after executing a larger load of queries following error occurs: "Error when getting batch 401:Unauthorized". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4919) Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.

by Ivan Chan (JIRA)

[ https://issues.jboss.org/browse/TEIID-4919?page=com.atlassian.jira.plugin... ] Ivan Chan commented on TEIID-4919: ---------------------------------- Let me try it out. I will get back to you soon. Thanks! > Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: TEIID-4919 > URL: https://issues.jboss.org/browse/TEIID-4919 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 9.1.1 > Reporter: Ivan Chan > Assignee: Steven Hawkins > > When I try to build VDB with sybase ASE 15.7 odb schema, I run into the following error: > Caused by: java.sql.SQLException: The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database. > at com.sybase.jdbc4.jdbc.SybConnection.getAllExceptions(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.handleSQLE(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.queryLoop(Unknown Source) > at com.sybase.jdbc4.jdbc.SybStatement.executeQuery(Unknown Source) > at com.sybase.jdbc4.jdbc.SybCallableStatement.executeQuery(Unknown Source) > at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.if(Unknown Source) > at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.getColumns(Unknown Source) > at org.apache.commons.dbcp.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:218) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getColumns(JDBCMetdataProcessor.java:382) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getTables(JDBCMetdataProcessor.java:334) > at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:173) > at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:306) > ... 182 more > I am using this driver: jconn4.jar [ com.sybase.jdbc4.jdbc.SybDriver ] > And org.teiid.translator.jdbc.sybase.SybaseExecutionFactor -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4858) hive translator is extremely slow

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4858. ----------------------------------- Resolution: Done After some testing, it does appear that the use of order by in hive introduces significantly more overhead than expected (comparing to Teiid or databases). Relying on Teiid sorting will generally be more performant. So the default support was changed and a release note added. We can revisit this if there are circumstances that still require order by pushdown. > hive translator is extremely slow > --------------------------------- > > Key: TEIID-4858 > URL: https://issues.jboss.org/browse/TEIID-4858 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Connector > Affects Versions: 8.12.9.6_3 > Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive > Reporter: Michael Echevarria > Assignee: Steven Hawkins > Fix For: 9.3 > > Attachments: fast.log, override1.png, override2.png, slow.log > > > When querying a table through the hive translator the results take close to 30 seconds to return. > When querying a table through jdbc default results take under 1 second to return. > Both use the same underlying jboss server datasource. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4858) hive translator is extremely slow

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4858: ---------------------------------- Fix Version/s: 9.2.4 > hive translator is extremely slow > --------------------------------- > > Key: TEIID-4858 > URL: https://issues.jboss.org/browse/TEIID-4858 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Connector > Affects Versions: 8.12.9.6_3 > Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive > Reporter: Michael Echevarria > Assignee: Steven Hawkins > Fix For: 9.3, 9.2.4 > > Attachments: fast.log, override1.png, override2.png, slow.log > > > When querying a table through the hive translator the results take close to 30 seconds to return. > When querying a table through jdbc default results take under 1 second to return. > Both use the same underlying jboss server datasource. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4920) [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4920?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4920. ----------------------------------- Assignee: Steven Hawkins (was: Barry LaFond) Resolution: Out of Date I can confirm this behavior in 8.10, but it does not occur 9.1+ I didn't yet track down a specific change that addressed this. What you should see instead are the errors: TEIID40046 VDB "test" version "1" does not exist. and TEIID31099 VDB test.1[...] is not active, but LOADING. If loading you can resubmit your query after loading has completed or after the errors have been corrected. > [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished > -------------------------------------------------------------------------------------------------------------- > > Key: TEIID-4920 > URL: https://issues.jboss.org/browse/TEIID-4920 > Project: Teiid > Issue Type: Bug > Components: Embedded, JDBC Connector, VDB > Affects Versions: 8.10 > Reporter: Krum Bakalsky > Assignee: Steven Hawkins > Priority: Minor > > Our application uses Embedded Teiid server, and upon starting up it first creates and starts the Teiid server, and then performs a VDB deployment on top of it: > {code} > void startApplication() { > createEmbeddedServer(); // 1 > deployVDB(); // 2 > } > createEmbeddedServer() method does the following: > { > EmbeddedConfiguration ec = createEmbeddedConfiguration(); > EmbeddedServer teiidServer = createEmbeddedTeiidServer(); > teiidServer.start(ec); > } > {code} > Step 2 - deployVDB() method - takes a while to complete, at minimum around 6-8 seconds. However, executing step 1 (creating and starting the embedded server) already creates its worker thread pool (the DQP pool), that is ready to serve incoming JDBC calls. > One of the reasons why we chose to perform these steps in that very order, is because of the [deployVDB|http://grepcode.com/file/repository.jboss.org/nexus/content/rep...] method: it first checks if the server is started and fails if that is not the case. So the order is somehow implied by the way Teiid deployment works. > This particular way of using Teiid is vulnerable to the following race condition: if client JDBC calls start coming while step 2 is not yet completed (VDB deployment is still in progress), then they will fail since the VDB metadata will be null: > {code} > 2017-02-14 11:18:12,250 ERROR org.teiid.PROCESSOR: TEIID30019 Unexpected exception for request <request_id> > org.teiid.core.TeiidComponentException: TEIID30489 Unable to load metadata for VDB <vdb_name>. > at org.teiid.dqp.internal.process.Request.initMetadata(Request.java:191) > at org.teiid.dqp.internal.process.Request.processRequest(Request.java:436) > at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:627) > at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:326) > at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) > at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:265) > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) > 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:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > Please advise of what is the safest way to achieve VDB deployment + server start, and in what order. > *Note*: Please note that this is probably not best categorized as a bug, but rather some glitch in the behavior of Embedded Teiid, or maybe even some misunderstanding about how deployment should be done w.r.t starting the embedded server. > I am assigning a minor priority since the impact of this problem is relatively small and limited - clients will be affected until VDB deployment is in progress. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4663) Support a more secure block mode for client/server encryption

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4663?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4663: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1451866|https://bugzilla.redhat.com/show_bug.cgi?id=1451866] from ASSIGNED to MODIFIED > Support a more secure block mode for client/server encryption > ------------------------------------------------------------- > > Key: TEIID-4663 > URL: https://issues.jboss.org/browse/TEIID-4663 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Driver, Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0.6, 9.1.2, 9.2, 8.12.x-6.4, 8.12.11.6_3 > > > ECB is the current default for the socket transport encryption of secure messages. While this is relatively ok for small messages as we also have a message key acting as a CTR counter to some of the blocks, it does not provide strong security - especially for large data volume scenarios, such as when using larger login payloads or the secure requests option. We should default instead to CBC with an explicit initialization vector. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4891) Fix and cleanup JDG quickstarts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4891?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4891: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1344292 Bugzilla Update: Perform > Fix and cleanup JDG quickstarts > ------------------------------- > > Key: TEIID-4891 > URL: https://issues.jboss.org/browse/TEIID-4891 > Project: Teiid > Issue Type: Task > Components: JDG Connector, Quick Starts > Affects Versions: 9.3, 8.12.x-6.4 > Reporter: Van Halbert > Assignee: Van Halbert > > Fix and clean up the JDG related quickstarts that include: > - update instructions > - update CLI scripts > - update vdb's > - update module dependencies -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4446) Rationalize precision/scale

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4446?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4446: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1451867|https://bugzilla.redhat.com/show_bug.cgi?id=1451867] from ASSIGNED to MODIFIED > Rationalize precision/scale > --------------------------- > > Key: TEIID-4446 > URL: https://issues.jboss.org/browse/TEIID-4446 > Project: Teiid > Issue Type: Quality Risk > Components: OData, ODBC, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.12.x-6.4, 8.12.11.6_3 > > > Our handling of precision/scale is inconsistent. There are assumptions being made in the JDBC client, types.dat, the parser, and other paths that need to be explicit and consistent. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2017