May 2017 - teiid-issues - Jboss List Archives

[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 commented on TEIID-4920: -------------------------------------- Thanks for your answer. Shall I assume that there is no way to effectively reverse the start-up order: first do the deployment, and only then start the server? I am OK if this is like that by design, just need to know. > [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-4930) Scale of 0 always reported for 0 precision

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4930: ------------------------------------- Summary: Scale of 0 always reported for 0 precision Key: TEIID-4930 URL: https://issues.jboss.org/browse/TEIID-4930 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.3 With invalid metadata from designer that specifies a 0 precision, the scale will always be reported as 0 as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4228) ODBC "Parse Statements" option can result in changes in LENGTH metadata for columns

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4228?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4228: --------------------------------------- The logic that adjusts the scale when it is larger than the precision does not account for a zero precision, they the 0 scale. I'll address this under a new issue, but generally it's a corner case as the incoming metadata is invalid. > ODBC "Parse Statements" option can result in changes in LENGTH metadata for columns > ----------------------------------------------------------------------------------- > > Key: TEIID-4228 > URL: https://issues.jboss.org/browse/TEIID-4228 > Project: Teiid > Issue Type: Sub-task > Components: ODBC > Affects Versions: 8.7 > Environment: Connections through ODBC driver > Reporter: Marc Shirley > Assignee: Steven Hawkins > Priority: Minor > Fix For: 9.1 > > > Connections through ODBC driver with the driver setting "Parse Statements" option enabled can result in incorrect length values being passed to the client. In some cases (such as SQL Server linked server capabilities), this can result in the client throwing exceptions due to the expected LENGTH changing during the course of the query execution. > This may be limited to columns with precision set to 0, as the SQL Server linked server case was corrected when the precision was changed from 0 to 9 for the column specified in the error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4572) Grouping by and faceted search for Solr tranlator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4572?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4572: --------------------------------------- 9.3 CR1 will go out this week. If we are assured that the pull request does not interfere with existing functionality and have not locked in on a single CR, then the pull request could go in next week at the latest. Otherwise it will need to wait until 10.0. > Grouping by and faceted search for Solr tranlator > ------------------------------------------------- > > Key: TEIID-4572 > URL: https://issues.jboss.org/browse/TEIID-4572 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Hend Amin > Fix For: 10.0 > > > Currently group by is not supported for Solr translator. For example: > select x,y, count\(*) from solr_core group by x,y; the corresponding Solr request does not contain group by. > Please add group by and faceted search support for Solr translator. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4925) Importing a non-existing VDB gives no warning

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4925?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4925. ----------------------------------- Fix Version/s: 9.3 Resolution: Done Added an info message that the vdb is waiting on importing another vdb. This may need to be made clearer in tooling - which would need to check for the loading state, then check for imported vdbs and their status. Otherwise it would require some rework in our VDBMetadata Messages, which are currently just schema/model based. > Importing a non-existing VDB gives no warning > --------------------------------------------- > > Key: TEIID-4925 > URL: https://issues.jboss.org/browse/TEIID-4925 > Project: Teiid > Issue Type: Enhancement > Components: Server > Affects Versions: 9.2.3 > Environment: * Wildfly 10 > * Teiid Server 9.2.3 > Reporter: Pedro Inácio > Assignee: Steven Hawkins > Fix For: 9.3 > > Attachments: ReferenceData.png > > > When importing a "non-existing VDB" in a VDB, when the VDB is deployed, the VDB status is LOADING, and nothing else happens. > Ideally a warning should be thrown in logs. > Ex: > <code> > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> > <vdb name="ReferenceDataVDB" version="1"> > <description>ReferenceData VDB</description> > <import-vdb name="NonExistingVDB" version="1"/> > > <model name="ReferenceData" type="VIRTUAL"> > ..... > </code> > Logs: > <panel> > 12:56:11,529 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "ReferenceData-vdb.xml" (runtime-name: "ReferenceData-vdb.xml") > 12:56:11,953 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "ReferenceData-vdb.xml" (runtime-name : "ReferenceData-vdb.xml") > </panel> -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4572) Grouping by and faceted search for Solr tranlator

by Amr Ismail (JIRA)

[ https://issues.jboss.org/browse/TEIID-4572?page=com.atlassian.jira.plugin... ] Amr Ismail commented on TEIID-4572: ----------------------------------- Dear Steven, We can work on this pull request on this week. So what is the deasline before moving this to the nexy version 10.x as we are in a hurry for releasing this version thanks > Grouping by and faceted search for Solr tranlator > ------------------------------------------------- > > Key: TEIID-4572 > URL: https://issues.jboss.org/browse/TEIID-4572 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Hend Amin > Fix For: 10.0 > > > Currently group by is not supported for Solr translator. For example: > select x,y, count\(*) from solr_core group by x,y; the corresponding Solr request does not contain group by. > Please add group by and faceted search support for Solr translator. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4572) Grouping by and faceted search for Solr tranlator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4572?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4572: ---------------------------------- Fix Version/s: 10.0 (was: 9.3) Moving to 10.x as we are still working through the pull request. > Grouping by and faceted search for Solr tranlator > ------------------------------------------------- > > Key: TEIID-4572 > URL: https://issues.jboss.org/browse/TEIID-4572 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Hend Amin > Fix For: 10.0 > > > Currently group by is not supported for Solr translator. For example: > select x,y, count\(*) from solr_core group by x,y; the corresponding Solr request does not contain group by. > Please add group by and faceted search support for Solr translator. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4928) Couchbase - NAMEINSOURCE required for all the columns and tables

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4928?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4928: --------------------------------------- Is the back quote required? If not, I don't think that we should try to automatically quote - especially since that would be different than the JDBC behavior. But yes, we should definitely not have a null table name. > Couchbase - NAMEINSOURCE required for all the columns and tables > ---------------------------------------------------------------- > > Key: TEIID-4928 > URL: https://issues.jboss.org/browse/TEIID-4928 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 9.3 > Reporter: Juraj Duráni > Assignee: Kylin Soong > > Option *NAMEINSOURCE* is de facto required for all the columns and tables. If it is not present then: > # column name in source query is not enclosed in back quotes - e.g. *`$cb_t1`.ShortValue* instead of *`$cb_t1`.`ShortValue`* > # name of the table is not added to the source query - e.g. *SELECT ... FROM null `$cb_t1` LET ... WHERE ...* instead of *SELECT ... FROM `smalla` `$cb_t1` LET ... WHERE ...* > This should work OOB without need to add NAMEINSOURCE option. Teiid should automatically translate column name from e.g. *MyColumn* to *`MyColumn`* if option is not set. Same with name of the table. > In case of table I think this is more serious as it does not even try name of the table but supplies *null* to the query -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4928) Couchbase - NAMEINSOURCE required for all the columns and tables

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4928?page=com.atlassian.jira.plugin... ] Van Halbert reassigned TEIID-4928: ---------------------------------- Assignee: Kylin Soong (was: Steven Hawkins) > Couchbase - NAMEINSOURCE required for all the columns and tables > ---------------------------------------------------------------- > > Key: TEIID-4928 > URL: https://issues.jboss.org/browse/TEIID-4928 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 9.3 > Reporter: Juraj Duráni > Assignee: Kylin Soong > > Option *NAMEINSOURCE* is de facto required for all the columns and tables. If it is not present then: > # column name in source query is not enclosed in back quotes - e.g. *`$cb_t1`.ShortValue* instead of *`$cb_t1`.`ShortValue`* > # name of the table is not added to the source query - e.g. *SELECT ... FROM null `$cb_t1` LET ... WHERE ...* instead of *SELECT ... FROM `smalla` `$cb_t1` LET ... WHERE ...* > This should work OOB without need to add NAMEINSOURCE option. Teiid should automatically translate column name from e.g. *MyColumn* to *`MyColumn`* if option is not set. Same with name of the table. > In case of table I think this is more serious as it does not even try name of the table but supplies *null* to the query -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4929) Add a User Guide for teiid spring boot starter

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-4929?page=com.atlassian.jira.plugin... ] Kylin Soong resolved TEIID-4929. -------------------------------- Resolution: Done > Add a User Guide for teiid spring boot starter > ---------------------------------------------- > > Key: TEIID-4929 > URL: https://issues.jboss.org/browse/TEIID-4929 > Project: Teiid > Issue Type: Sub-task > Components: Documentation > Reporter: Kylin Soong > Assignee: Kylin Soong > Fix For: 10.0 > > > Need some document for how to use teiid spring boot starter. -- 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