[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:
---------------------------------------
The recommendation from https://community.microstrategy.com/t5/Architect/TN39839-quot-The-CREATE-...
Is to alter a sybase server setting. Is that an appropriate workaround for you?
> 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
[JBoss JIRA] (TEIID-4921) Couchbase Translator test failures
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4921?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4921:
-------------------------------
Priority: Blocker (was: Major)
> Couchbase Translator test failures
> ----------------------------------
>
> Key: TEIID-4921
> URL: https://issues.jboss.org/browse/TEIID-4921
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Van Halbert
> Assignee: Kylin Soong
> Priority: Blocker
> Attachments: TEST-org.teiid.translator.couchbase.TestCouchbaseMetadataProcessor.xml, TEST-org.teiid.translator.couchbase.TestN1QLUpdateVisitor.xml, TEST-org.teiid.translator.couchbase.TestN1QLVisitor.xml
>
>
> Attached are the current failures in the translator-couchbase on the 64-8.12.x branch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (TEIID-4921) Couchbase Translator test failures
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4921?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4921:
-------------------------------
Attachment: TEST-org.teiid.translator.couchbase.TestCouchbaseMetadataProcessor.xml
TEST-org.teiid.translator.couchbase.TestN1QLUpdateVisitor.xml
TEST-org.teiid.translator.couchbase.TestN1QLVisitor.xml
> Couchbase Translator test failures
> ----------------------------------
>
> Key: TEIID-4921
> URL: https://issues.jboss.org/browse/TEIID-4921
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Van Halbert
> Assignee: Kylin Soong
> Attachments: TEST-org.teiid.translator.couchbase.TestCouchbaseMetadataProcessor.xml, TEST-org.teiid.translator.couchbase.TestN1QLUpdateVisitor.xml, TEST-org.teiid.translator.couchbase.TestN1QLVisitor.xml
>
>
> Attached are the current failures in the translator-couchbase on the 64-8.12.x branch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (TEIID-4921) Couchbase Translator test failures
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4921?page=com.atlassian.jira.plugin... ]
Van Halbert reassigned TEIID-4921:
----------------------------------
Assignee: Kylin Soong (was: Steven Hawkins)
> Couchbase Translator test failures
> ----------------------------------
>
> Key: TEIID-4921
> URL: https://issues.jboss.org/browse/TEIID-4921
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Van Halbert
> Assignee: Kylin Soong
> Attachments: TEST-org.teiid.translator.couchbase.TestCouchbaseMetadataProcessor.xml, TEST-org.teiid.translator.couchbase.TestN1QLUpdateVisitor.xml, TEST-org.teiid.translator.couchbase.TestN1QLVisitor.xml
>
>
> Attached are the current failures in the translator-couchbase on the 64-8.12.x branch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (TEIID-4921) Couchbase Translator test failures
by Van Halbert (JIRA)
Van Halbert created TEIID-4921:
----------------------------------
Summary: Couchbase Translator test failures
Key: TEIID-4921
URL: https://issues.jboss.org/browse/TEIID-4921
Project: Teiid
Issue Type: Bug
Components: Misc. Connectors
Affects Versions: 8.12.x-6.4
Reporter: Van Halbert
Assignee: Steven Hawkins
Attached are the current failures in the translator-couchbase on the 64-8.12.x branch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (TEIID-4920) [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished
by Krum Bakalsky (JIRA)
[ https://issues.jboss.org/browse/TEIID-4920?page=com.atlassian.jira.plugin... ]
Krum Bakalsky updated TEIID-4920:
---------------------------------
Description:
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.
was:
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}
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.
> [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: Barry LaFond
> 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
[JBoss JIRA] (TEIID-4920) [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished
by Krum Bakalsky (JIRA)
Krum Bakalsky created TEIID-4920:
------------------------------------
Summary: [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: Barry LaFond
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}
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
[JBoss JIRA] (TEIID-4722) TEIID30019: java.lang.AssertionError: Assertion failed assertion due to guard against a corner condition.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4722?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4722:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1451865|https://bugzilla.redhat.com/show_bug.cgi?id=1451865] from NEW to ASSIGNED
> TEIID30019: java.lang.AssertionError: Assertion failed assertion due to guard against a corner condition.
> -----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4722
> URL: https://issues.jboss.org/browse/TEIID-4722
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.10.6_2
> Reporter: Johnathon Lee
> Assignee: Steven Hawkins
> Fix For: 9.2, 9.1.3, 8.7.12.6_2, 8.12.x-6.4, 8.12.11.6_3
>
>
> Assertion failure:
> {code:java}
> ERROR [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue19151) TEIID30019 Unexpected exception for request WrzxYIqVWQ8G.11: java.lang.AssertionError: Assertion failed.
> at org.teiid.core.util.Assertion.failed(Assertion.java:73) [teiid-common-core-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2]
> at org.teiid.core.util.Assertion.assertTrue(Assertion.java:68) [teiid-common-core-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2]
> at org.teiid.core.util.Assertion.assertTrue(Assertion.java:60) [teiid-common-core-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2]
> at org.teiid.query.processor.relational.MergeJoinStrategy.setProcessingSortRight(MergeJoinStrategy.java:367) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2]
> at org.teiid.query.processor.relational.DependentAccessNode.prepareNextCommand(DependentAccessNode.java:162) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2]
> at org.teiid.query.processor.relational.AccessNode.openInternal(AccessNode.java:259) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2]
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:371) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.10.6_2-redhat-2.jar:8.7.10.6_2-redhat-2]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months