[JBoss JIRA] (TEIID-5650) MongoDB: The DB interface is deprecated
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5650?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5650:
----------------------------------
Fix Version/s: 12.x
> MongoDB: The DB interface is deprecated
> ---------------------------------------
>
> Key: TEIID-5650
> URL: https://issues.jboss.org/browse/TEIID-5650
> Project: Teiid
> Issue Type: Task
> Components: Misc. Connectors
> Affects Versions: 12.0
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.x
>
>
> The interface that presents the connection to the MongoDB `MongoDBConnection` uses interface `DB` from Mongo driver is deprecated and slated to removed in future versions of the Mongo Driver Java client. This needs to be updated to `MongoDatabase` interface.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (TEIID-5650) MongoDB: The DB interface is deprecated
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5650?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5650:
---------------------------------------
There are further simplifications that we can make if we cut off support for pre-2.6.
> MongoDB: The DB interface is deprecated
> ---------------------------------------
>
> Key: TEIID-5650
> URL: https://issues.jboss.org/browse/TEIID-5650
> Project: Teiid
> Issue Type: Task
> Components: Misc. Connectors
> Affects Versions: 12.0
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Major
>
> The interface that presents the connection to the MongoDB `MongoDBConnection` uses interface `DB` from Mongo driver is deprecated and slated to removed in future versions of the Mongo Driver Java client. This needs to be updated to `MongoDatabase` interface.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (TEIID-5650) MongoDB: The DB interface is deprecated
by Ramesh Reddy (Jira)
Ramesh Reddy created TEIID-5650:
-----------------------------------
Summary: MongoDB: The DB interface is deprecated
Key: TEIID-5650
URL: https://issues.jboss.org/browse/TEIID-5650
Project: Teiid
Issue Type: Task
Components: Misc. Connectors
Affects Versions: 12.0
Reporter: Ramesh Reddy
Assignee: Steven Hawkins
The interface that presents the connection to the MongoDB `MongoDBConnection` uses interface `DB` from Mongo driver is deprecated and slated to removed in future versions of the Mongo Driver Java client. This needs to be updated to `MongoDatabase` interface.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (TEIID-5643) When querying a larger dataset, teiid answers with 504 Gateway Time-out and throws exception
by Christoph John (Jira)
[ https://issues.jboss.org/browse/TEIID-5643?page=com.atlassian.jira.plugin... ]
Christoph John commented on TEIID-5643:
---------------------------------------
Hello Steven,
thanks for the reply. The useCursorFetch topic sounds reasonable. I am currently trying to set the parameter, but I have not understood yet, how I can set it in Teiid. Not so easy to get this info out of the documentation.
I tried out the following two variants. Both tries were to set the data source in standalone-teiid.xml
Variant 1:
<datasource jndi-name="java:/my_nutri_diary" pool-name="my_nutri_diary" enabled="true" use-ccm="false">
<connection-url>jdbc:mysql://db:3306/my_nutri_diary;useCursorFetch=true</connection-url>
<driver>mysql</driver>
This variant was taken from the example at http://javari.blogspot.com/2017/01/. But unfortunately this results in errors when sending a query to teiid.
TEIID30504 my_nutri_diary: TEIID11009 java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/my_nutri_diary
So I assume, this was the wrong way to set the parameter :)
Variant 2: Taken from https://developer.jboss.org/thread/248588
<datasource jndi-name="java:/my_nutri_diary" pool-name="my_nutri_diary" enabled="true" use-ccm="false">
<connection-url>jdbc:mysql://db:3306/my_nutri_diary?useCursorFetch=true</connection-url>
<driver>mysql</driver>
This variant does not result in errors on requests in general. But for my large table it seems to have no effect at all. I still get the same 504 Gateway Time-out error which I got without setting the parameter. Is the second option the correct way to set the parameter or is it also wrong how I did it?
It would be very great if you could provide an example on how to set the parameter. What is also not clear to me from the documentation you have referenced is, if I also explicitly have to set defaultFetchSize as well. Or does Teiid automatically use the fetch size given in the web.xml on each request and I just have to set useCursorFetch=true? Thanks for your help!
> When querying a larger dataset, teiid answers with 504 Gateway Time-out and throws exception
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-5643
> URL: https://issues.jboss.org/browse/TEIID-5643
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 11.2.1
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: Heap Dump analysis tool.pdf
>
>
> Please note, I am using Teiid 11.2.0 and not 11.2.1 as specified above in this ticket. I was not able to select a version 11.2.0.
> The issue: I tried to query a table with a larger amount of records (about 600.000 records in the table). Teiid responds with
> 504 Gateway Time-out. The server didn't respond in time.
> If Teiid tries to respond with 600.000 entries to such a request, it is reasonable that it runs out of memory or other weird things happen. However, I would expect that in such a case Teiid just answers with a fixed amount of records, say for example 1000, and provides a kind of curser to enable subsequent requests to retrieve more data.
> I am currently trying to find a workaround for the issue, as the issue blocks my work. Is there maybe a kind of configuration option that I have to set explicitly for such a kind of behavior I previously sketched?
> Further note: When I send such a kind of select * request on the table to Teiid, I am also not able for a certain time interval, about a minute, to get a responds to different queries which select a single element on the mentioned table. Such a request then also results in a 504 Gateway Time-out.
> Attached error log:
> 2019-02-01 22:33:36,126 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (Worker2_QueryProcessorQueue5) eayVFuq9y7OY IJ000407: No lazy enlistment available for my_nutri_diary
> 2019-02-01 22:33:36,135 INFO [org.teiid.CONNECTOR] (Worker2_QueryProcessorQueue5) eayVFuq9y7OY MySQLExecutionFactory Commit=true;DatabaseProductName=MySQL;DatabaseProductVersion=8.0.13;DriverMajorVersion=8;DriverMajorVersion=0;DriverName=MySQL Connector/J;DriverVersion=mysql-connector-java-8.0.13 (Revision: 66459e9d39c8fd09767992bc592acd2053279be6);IsolationLevel=2
> 2019-02-01 22:36:56,959 WARN [org.teiid.CONNECTOR] (Worker2_QueryProcessorQueue5) eayVFuq9y7OY Connector worker process failed for atomic-request=eayVFuq9y7OY.0.0.0: org.teiid.translator.jdbc.JDBCExecutionException: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.`idCode` AS c_0, g_0.`lc` AS c_1, g_0.`product_name` AS c_2, g_0.`origins` AS c_3, g_0.`brands` AS c_4, g_0.`quantity` AS c_5, g_0.`nova_group` AS c_6, g_0.`nutrition_grade_fr` AS c_7, g_0.`ingredients_text_with_allergens` AS c_8, g_0.`energy_100g` AS c_9, g_0.`carbohydrates_100g` AS c_10, g_0.`sugars_100g` AS c_11, g_0.`proteins_100g` AS c_12, g_0.`fat_100g` AS c_13, g_0.`saturated_fat_100g` AS c_14, g_0.`saturated_fat_modifier` AS c_15, g_0.`salt_100g` AS c_16, g_0.`sodium_100g` AS c_17 FROM `FDBProducts` AS g_0 ORDER BY c_0]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:127)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:229)
> at com.sun.proxy.$Proxy51.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:302)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:104)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:61)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:278)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.sql.SQLException: Java heap space
> at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:129)
> at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
> at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
> at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:974)
> at com.mysql.cj.jdbc.ClientPreparedStatement.executeQuery(ClientPreparedStatement.java:1024)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:504)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:119)
> ... 18 more
> 2019-02-01 22:36:56,977 WARN [org.teiid.PROCESSOR] (default task-4) eayVFuq9y7OY TEIID30020 Processing exception for request eayVFuq9y7OY.0 'TEIID30504 my_nutri_diary: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.`idCode` AS c_0, g_0.`lc` AS c_1, g_0.`product_name` AS c_2, g_0.`origins` AS c_3, g_0.`brands` AS c_4, g_0.`quantity` AS c_5, g_0.`nova_group` AS c_6, g_0.`nutrition_grade_fr` AS c_7, g_0.`ingredients_text_with_allergens` AS c_8, g_0.`energy_100g` AS c_9, g_0.`carbohydrates_100g` AS c_10, g_0.`sugars_100g` AS c_11, g_0.`proteins_100g` AS c_12, g_0.`fat_100g` AS c_13, g_0.`saturated_fat_100g` AS c_14, g_0.`saturated_fat_modifier` AS c_15, g_0.`salt_100g` AS c_16, g_0.`sodium_100g` AS c_17 FROM `FDBProducts` AS g_0 ORDER BY c_0]'. Originally TeiidProcessingException 'Java heap space' SQLError.java:129. Enable more detailed logging to see the entire stacktrace.
> 2019-02-01 22:36:56,987 WARN [org.teiid.PROCESSOR] (default task-4) TEIID16053 Unable to process odata request due to: TEIID30504 my_nutri_diary: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.`idCode` AS c_0, g_0.`lc` AS c_1, g_0.`product_name` AS c_2, g_0.`origins` AS c_3, g_0.`brands` AS c_4, g_0.`quantity` AS c_5, g_0.`nova_group` AS c_6, g_0.`nutrition_grade_fr` AS c_7, g_0.`ingredients_text_with_allergens` AS c_8, g_0.`energy_100g` AS c_9, g_0.`carbohydrates_100g` AS c_10, g_0.`sugars_100g` AS c_11, g_0.`proteins_100g` AS c_12, g_0.`fat_100g` AS c_13, g_0.`saturated_fat_100g` AS c_14, g_0.`saturated_fat_modifier` AS c_15, g_0.`salt_100g` AS c_16, g_0.`sodium_100g` AS c_17 FROM `FDBProducts` AS g_0 ORDER BY c_0] Increase the log level to see the entire stack trace.
> 2019-02-01 22:36:57,213 WARN [org.teiid.CONNECTOR] (Worker2_QueryProcessorQueue6) NdaDihMR2Vlt Connector worker process failed for atomic-request=NdaDihMR2Vlt.0.0.1: org.teiid.translator.jdbc.JDBCExecutionException: 0 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.`idCode` AS c_0, g_0.`lc` AS c_1, g_0.`product_name` AS c_2, g_0.`origins` AS c_3, g_0.`brands` AS c_4, g_0.`quantity` AS c_5, g_0.`nova_group` AS c_6, g_0.`nutrition_grade_fr` AS c_7, g_0.`ingredients_text_with_allergens` AS c_8, g_0.`energy_100g` AS c_9, g_0.`carbohydrates_100g` AS c_10, g_0.`sugars_100g` AS c_11, g_0.`proteins_100g` AS c_12, g_0.`fat_100g` AS c_13, g_0.`saturated_fat_100g` AS c_14, g_0.`saturated_fat_modifier` AS c_15, g_0.`salt_100g` AS c_16, g_0.`sodium_100g` AS c_17 FROM `FDBProducts` AS g_0 ORDER BY c_0]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:127)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:229)
> at com.sun.proxy.$Proxy51.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:302)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:104)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:61)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:278)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (TEIID-5640) Don't provide access to system schema over odata
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5640?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5640.
-----------------------------------
Resolution: Done
Changed the logic to make system schema hidden with a release note about the change to add views/procedures as needed to provide access. If someone has a compelling case we can consider adding a flag to control this behavior.
> Don't provide access to system schema over odata
> ------------------------------------------------
>
> Key: TEIID-5640
> URL: https://issues.jboss.org/browse/TEIID-5640
> Project: Teiid
> Issue Type: Quality Risk
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.1
>
>
> We now create all of the edm metadata at once - including for system schema - but we should not allow that by default.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (TEIID-5649) Isolate wildfly/cli dependent documentation
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5649:
-------------------------------------
Summary: Isolate wildfly/cli dependent documentation
Key: TEIID-5649
URL: https://issues.jboss.org/browse/TEIID-5649
Project: Teiid
Issue Type: Quality Risk
Components: Documentation
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.1
To better support or various environments we need to isolate docs in the main set that are dependent upon wildfly/cli.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (TEIID-5648) Hide metadata over odata
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5648?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5648:
----------------------------------
Fix Version/s: 12.x
> Hide metadata over odata
> ------------------------
>
> Key: TEIID-5648
> URL: https://issues.jboss.org/browse/TEIID-5648
> Project: Teiid
> Issue Type: Quality Risk
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.x
>
>
> All schemas, not marked as hidden, will be visible over odata. This includes all schema objects. Via the other access mechanisms permission is now required for visibility - TEIID-5516 and TEIID-2476.
> Alternatively there could also be an option to still expose the metadata by default for non-odata access even if the user is not permissioned.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months