[JBoss JIRA] (TEIID-4928) Couchbase - NAMEINSOURCE required for all the columns and tables
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-4928?page=com.atlassian.jira.plugin... ]
Juraj Duráni commented on TEIID-4928:
-------------------------------------
[~kylin]
>> This for compatible with N1QL reference...
How is it compatible? If _NAMEINSOURCE _is not defined for column, generated N1QL is missing back quotes \(`\) around _ShortValue_ which, from my testing, does not work.
>> Yes, this is default design pattern, not that, the couchbase server don't have any schema...
Not adding table name to N1QL is a default design pattern?
I think I am not confused about converting SQL to N1QL. What I am worried about is *...FROM null...* in generated N1QL if _NAMEINSOURCE_ is not defined.
>> I think it's not possible to pass a null,...
Obviously it is.
>> Also It's not recommend to define the table by your self,...
Not recommended does not mean not supported.
Defining DDL metadata in source mode has some advantages over NATIVE metadata. Moreover, what if one bucket contains documents with more than one "schema"? How can you be so sure that you will fetch enough documents to infer all related schemas? Should user set *importer.sampleSize* property to 1,000,000? Or even more? What is Teiid's "oracle" according to which you fetch documents from Couchbase?
If you let user define her/his own schema, you will avoid user's frustration of Teiid not being able to infer proper schemas/tables from sample documents. And of course, this should be as simple as possible. Without requiring user to define any of OPTIONS.
In fact, after talking with other QE we would not recommend using NATIVE metadata for Couchbase.
> 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)
7 years, 7 months
[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:
---------------------------------------
As mentioned on the original pull request, the SolrQueryExecution changes seem to have issues or need clarification:
- There are quite a few checks for a column of type timestamp (in particular findTimestampIndex) - but it doesn't appear that there is a guarantee it will be the correct column. That is you could easily have the gap on one field and group by another timestamp column.
- Why is adjustDateFormat needed now, but wasn't needed before?
- The this.visitor.isCountStarInUse() logic is only enabled in faceted scenario. It looks like "select count(\*\) from tbl" won't work as expected.
I would like to see unit tests of the execution logic, or perhaps you could provide a docker image of a representative solr instance to aid in testing.
> 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)
7 years, 7 months
[JBoss JIRA] (TEIID-4928) Couchbase - NAMEINSOURCE required for all the columns and tables
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4928?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4928:
------------------------------------
[~shawkins], current Couchbase, MongoDB translator may confused user, because the translator already auto-generated lots of tables,
But users not aware this, they usually define the tables by themself. The Simba has a schema tools and lots of documents let users know if you want use Simba driver, first you need generate schema file, if user supply this file, the Simba driver will not re-generate.
Do you think how can we do some enhance to make this more clear?
> 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)
7 years, 7 months
[JBoss JIRA] (TEIID-4928) Couchbase - NAMEINSOURCE required for all the columns and tables
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4928?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4928:
------------------------------------
Thanks [~jdurani] for report,
> column name in source query is not enclosed in back quotes - e.g. `$cb_t1`.ShortValue instead of `$cb_t1`.`ShortValue`
This for compatible with N1QL reference
> 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 ...
Yes, this is default design pattern, not that, the couchbase server don't have any schema(the schema generated on translator load metadata), the couchabse server only contain the documents under keyspace, a sql query against a table will convert to a n1ql query against couchbase keyspace, so it's may confused if you deving into the souce query. [1] has some souce query N1QL, you can have a look at.
> 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
I think it's not possible to pass a null, cause the table name in schema are strict 1-to-1 mapped with keyspace name in Couchbase server. Also It's not recommend to define the table by your self, the schema are auto-generated, you just need to use the generated ones, refer to [2] for details about schema generation, the parent folder of [1] also has lots of .expected file, it contain the auto-generated schema.
[1] https://github.com/teiid/teiid/blob/master/connectors/couchbase/translato...
[2] https://teiid.gitbooks.io/documents/content/reference/couchbase_translato...
> 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)
7 years, 7 months
[JBoss JIRA] (TEIID-4926) Couchbase - unable to retrieve data if using 'convert' in view definition
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4926?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4926:
------------------------------------
Van
How can I push a commit to a remote branch? I have tried ceate PR just like normal add a pull request, it hints there are 250 commits need to push to 64-8.12.x, I think this not make sense. :)
I also try the https://stackoverflow.com/questions/3230074/how-can-i-pushing-specific-co..., but I think I don't have enough rights to write to a remote branch.
Kylin
> Couchbase - unable to retrieve data if using 'convert' in view definition
> -------------------------------------------------------------------------
>
> Key: TEIID-4926
> URL: https://issues.jboss.org/browse/TEIID-4926
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.3
> Reporter: Juraj Duráni
> Assignee: Kylin Soong
> Priority: Blocker
>
> I have a simple document structure in Couchbase (no nested documents, all values are strings, integers, and booleans).
> I have a source model with proper types (strings, integers, booleans) and view model defined with my target types (float, double, date,...) all with appropriate conversion.
> There are basically two issues:
> - When I try to retrieve all data from the view, Teiid ends with exception \[1\]. This is wired.
> - When I try to use explicit convert on some columns from source table (not view) it ends with similar exception \[2\].
> Additional information:
> I represent 'Null' values by excluding key from the document (nevertheless, same error occurs even if I add explicit "key":null to the definition of the document).
> \[1\]
> TEIID10076 Invalid conversion from type class java.lang.Integer with value '-24' to type class java.sql.Date
> \[2\] - case for data value
> TEIID10076 Invalid conversion from type class java.lang.Object with value '\{\}' to type class java.sql.Date
> \[3\] - Queries
> {code:sql}
> OK - select * from couchbase.smalla
> FAIL - select * from bqt1.smalla
> FAIL - select convert(datevalue, date) from couchbase.smalla
> {code}
> \[4\] VDB definition
> {code:sql}
> -- source model
> SET NAMESPACE 'http://www.teiid.org/translator/couchbase/2017' AS teiid_couchbase;
> CREATE FOREIGN TABLE SmallA (
> documentID string,
> FloatNum integer OPTIONS (NAMEINSOURCE '`smalla`.`FloatNum`'),
> IntKey integer PRIMARY KEY OPTIONS (NAMEINSOURCE '`smalla`.`IntKey`'),
> BigIntegerValue integer OPTIONS (NAMEINSOURCE '`smalla`.`BigIntegerValue`'),
> StringKey string OPTIONS (NAMEINSOURCE '`smalla`.`StringKey`'),
> CharValue string OPTIONS (NAMEINSOURCE '`smalla`.`CharValue`'),
> LongNum integer OPTIONS (NAMEINSOURCE '`smalla`.`LongNum`'),
> type string OPTIONS (NAMEINSOURCE '`smalla`.`type`'),
> DoubleNum integer OPTIONS (NAMEINSOURCE '`smalla`.`DoubleNum`'),
> ObjectValue string OPTIONS (NAMEINSOURCE '`smalla`.`ObjectValue`'),
> ShortValue integer OPTIONS (NAMEINSOURCE '`smalla`.`ShortValue`'),
> BigDecimalValue integer OPTIONS (NAMEINSOURCE '`smalla`.`BigDecimalValue`'),
> DateValue string OPTIONS (NAMEINSOURCE '`smalla`.`DateValue`'),
> BooleanValue boolean OPTIONS (NAMEINSOURCE '`smalla`.`BooleanValue`'),
> TimestampValue string OPTIONS (NAMEINSOURCE '`smalla`.`TimestampValue`'),
> ByteNum integer OPTIONS (NAMEINSOURCE '`smalla`.`ByteNum`'),
> StringNum string OPTIONS (NAMEINSOURCE '`smalla`.`StringNum`'),
> TimeValue string OPTIONS (NAMEINSOURCE '`smalla`.`TimeValue`'),
> IntNum integer OPTIONS (NAMEINSOURCE '`smalla`.`IntNum`')
> ) OPTIONS (NAMEINSOURCE '`smalla`', UPDATABLE FALSE, "teiid_couchbase:ISARRAYTABLE" 'false', "teiid_couchbase:NAMEDTYPEPAIR" '`type`:''SmallA''');
> -- view model
> CREATE VIEW SmallA (
> IntKey integer PRIMARY KEY,
> StringKey string,
> IntNum integer,
> StringNum string,
> FloatNum float,
> LongNum long,
> DoubleNum double,
> ByteNum byte,
> DateValue date,
> TimeValue time,
> TimestampValue timestamp,
> BooleanValue boolean,
> CharValue char(1),
> ShortValue short,
> BigIntegerValue biginteger,
> BigDecimalValue bigdecimal,
> ObjectValue object)
> AS
> SELECT
> IntKey, StringKey, IntNum, StringNum, convert(FloatNum, float) AS FloatNum, convert(LongNum, long) AS LongNum,
> convert(DoubleNum, double) AS DoubleNum, convert(ByteNum, byte) AS ByteNum, convert(DateValue, date) AS DateValue,
> convert(TimeValue, time) AS TimeValue, convert(TimestampValue, timestamp) AS TimstampValue, BooleanValue,
> convert(CharValue, char) AS CharValue, convert(ShortValue, short) AS ShortValue, convert(BigIntegerValue, biginteger) AS BigIntegerValue,
> convert(BigDecimalValue, bigdecimal) AS BigDecimalValue, convert(ObjectValue, object) AS ObjectValue
> FROM
> Couchbase.SmallA;
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (TEIID-4926) Couchbase - unable to retrieve data if using 'convert' in view definition
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4926?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4926:
------------------------------------
Thanks [~jdurani] report, I have add a PR(https://github.com/teiid/teiid/pull/960), could you verify after the PR merged?
> Couchbase - unable to retrieve data if using 'convert' in view definition
> -------------------------------------------------------------------------
>
> Key: TEIID-4926
> URL: https://issues.jboss.org/browse/TEIID-4926
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.3
> Reporter: Juraj Duráni
> Assignee: Kylin Soong
> Priority: Blocker
>
> I have a simple document structure in Couchbase (no nested documents, all values are strings, integers, and booleans).
> I have a source model with proper types (strings, integers, booleans) and view model defined with my target types (float, double, date,...) all with appropriate conversion.
> There are basically two issues:
> - When I try to retrieve all data from the view, Teiid ends with exception \[1\]. This is wired.
> - When I try to use explicit convert on some columns from source table (not view) it ends with similar exception \[2\].
> Additional information:
> I represent 'Null' values by excluding key from the document (nevertheless, same error occurs even if I add explicit "key":null to the definition of the document).
> \[1\]
> TEIID10076 Invalid conversion from type class java.lang.Integer with value '-24' to type class java.sql.Date
> \[2\] - case for data value
> TEIID10076 Invalid conversion from type class java.lang.Object with value '\{\}' to type class java.sql.Date
> \[3\] - Queries
> {code:sql}
> OK - select * from couchbase.smalla
> FAIL - select * from bqt1.smalla
> FAIL - select convert(datevalue, date) from couchbase.smalla
> {code}
> \[4\] VDB definition
> {code:sql}
> -- source model
> SET NAMESPACE 'http://www.teiid.org/translator/couchbase/2017' AS teiid_couchbase;
> CREATE FOREIGN TABLE SmallA (
> documentID string,
> FloatNum integer OPTIONS (NAMEINSOURCE '`smalla`.`FloatNum`'),
> IntKey integer PRIMARY KEY OPTIONS (NAMEINSOURCE '`smalla`.`IntKey`'),
> BigIntegerValue integer OPTIONS (NAMEINSOURCE '`smalla`.`BigIntegerValue`'),
> StringKey string OPTIONS (NAMEINSOURCE '`smalla`.`StringKey`'),
> CharValue string OPTIONS (NAMEINSOURCE '`smalla`.`CharValue`'),
> LongNum integer OPTIONS (NAMEINSOURCE '`smalla`.`LongNum`'),
> type string OPTIONS (NAMEINSOURCE '`smalla`.`type`'),
> DoubleNum integer OPTIONS (NAMEINSOURCE '`smalla`.`DoubleNum`'),
> ObjectValue string OPTIONS (NAMEINSOURCE '`smalla`.`ObjectValue`'),
> ShortValue integer OPTIONS (NAMEINSOURCE '`smalla`.`ShortValue`'),
> BigDecimalValue integer OPTIONS (NAMEINSOURCE '`smalla`.`BigDecimalValue`'),
> DateValue string OPTIONS (NAMEINSOURCE '`smalla`.`DateValue`'),
> BooleanValue boolean OPTIONS (NAMEINSOURCE '`smalla`.`BooleanValue`'),
> TimestampValue string OPTIONS (NAMEINSOURCE '`smalla`.`TimestampValue`'),
> ByteNum integer OPTIONS (NAMEINSOURCE '`smalla`.`ByteNum`'),
> StringNum string OPTIONS (NAMEINSOURCE '`smalla`.`StringNum`'),
> TimeValue string OPTIONS (NAMEINSOURCE '`smalla`.`TimeValue`'),
> IntNum integer OPTIONS (NAMEINSOURCE '`smalla`.`IntNum`')
> ) OPTIONS (NAMEINSOURCE '`smalla`', UPDATABLE FALSE, "teiid_couchbase:ISARRAYTABLE" 'false', "teiid_couchbase:NAMEDTYPEPAIR" '`type`:''SmallA''');
> -- view model
> CREATE VIEW SmallA (
> IntKey integer PRIMARY KEY,
> StringKey string,
> IntNum integer,
> StringNum string,
> FloatNum float,
> LongNum long,
> DoubleNum double,
> ByteNum byte,
> DateValue date,
> TimeValue time,
> TimestampValue timestamp,
> BooleanValue boolean,
> CharValue char(1),
> ShortValue short,
> BigIntegerValue biginteger,
> BigDecimalValue bigdecimal,
> ObjectValue object)
> AS
> SELECT
> IntKey, StringKey, IntNum, StringNum, convert(FloatNum, float) AS FloatNum, convert(LongNum, long) AS LongNum,
> convert(DoubleNum, double) AS DoubleNum, convert(ByteNum, byte) AS ByteNum, convert(DateValue, date) AS DateValue,
> convert(TimeValue, time) AS TimeValue, convert(TimestampValue, timestamp) AS TimstampValue, BooleanValue,
> convert(CharValue, char) AS CharValue, convert(ShortValue, short) AS ShortValue, convert(BigIntegerValue, biginteger) AS BigIntegerValue,
> convert(BigDecimalValue, bigdecimal) AS BigDecimalValue, convert(ObjectValue, object) AS ObjectValue
> FROM
> Couchbase.SmallA;
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[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,
Could you please specify exactly what methods need to be improved to start
working on them today as I don't see any more enhancements to be done.
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)
7 years, 7 months
[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 commented on TEIID-4920:
---------------------------------------
Yes, there is no way without a code change to reverse the startup order. This also mimics the behavior of Teiid running in a container as the vdb deployments are happening simultaneously with starting the transports. There is also a wait_for_load parameter that may attempt a connection before the vdb is deployed/available that can mitigate seeing the intermediate exceptions when connecting.
> [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)
7 years, 7 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 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)
7 years, 7 months