[JBoss JIRA] (TEIID-3583) Need documentation on possible property settings to use
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3583?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3583:
---------------------------------------
Expanded on Kylin's commit. There were also tests in TestLocalBufferService, but not a single place showing all scalings.
Also updated the doc to de-emphasize modifying max-processing-kb.
> Need documentation on possible property settings to use
> -------------------------------------------------------
>
> Key: TEIID-3583
> URL: https://issues.jboss.org/browse/TEIID-3583
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> In the Administration and Configuration Guide there is some indication on how to perform active heap throttling.
> "Memory Management Considerations " there is a reference to parameters like:
> max-processing-kb and the max-reserve-kb.
> Anyway there is no indication of the indicative values to associate to those parameters to obtain a certain result.
> It would be good to get some examples to understand the cause and effect of the changes ( max-reserve-kb and related settings ).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (TEIID-3485) Decompose joins only works with a single join
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3485?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3485:
---------------------------------------
I likely won't address the multi-way case as it would be uncommon to have for example a non-partitioned bridging table separating two partitioned tables. The view case should be workable though by projecting the partition info upwards.
> Decompose joins only works with a single join
> ---------------------------------------------
>
> Key: TEIID-3485
> URL: https://issues.jboss.org/browse/TEIID-3485
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> A multi-way join or joins through non-removable view layers cannot currently be decomposed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (TEIID-3589) MongoDB metadata import fails with NPE
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3589?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3589.
---------------------------------
Labels: Alpha2 (was: )
Fix Version/s: 8.7.1.6_2
8.12
Resolution: Done
Added the null check to avoid reading through the empty collections. In this case the table creation for the empty collection is avoided.
> MongoDB metadata import fails with NPE
> --------------------------------------
>
> Key: TEIID-3589
> URL: https://issues.jboss.org/browse/TEIID-3589
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.7.1.6_2
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Labels: Alpha2
> Fix For: 8.7.1.6_2, 8.12
>
>
> Deploying the following dynamic vdb fails with a NullPointerException when Teiid Connection importer is used:
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="mongo" version="1">
> <description>Importer VDB</description>
> <property name="UseConnectorMetadata" value="true" />
> <property name="deployment-name" value="mongo-vdb.xml" />
> <model name="importVDBSrcModel">
> <source name="importVDBSrcModel" translator-name="mongodb" connection-jndi-name="java:/mongoDS" />
> </model>
> </vdb>
> The resource adapter is defined as:
> <resource-adapter id="mongoDS">
> <module slot="main" id="org.jboss.teiid.resource-adapter.mongodb"/>
> <transaction-support>NoTransaction</transaction-support>
> <connection-definitions>
> <connection-definition class-name="org.teiid.resource.adapter.mongodb.MongoDBManagedConnectionFactory" jndi-name="java:/mongoDS" enabled="true" use-java-context="true" pool-name="mongoDS">
> <config-property name="Database">
> bqt
> </config-property>
> <config-property name="RemoteServerList">
> vmgdb01.mw.lab.eng.bos.redhat.com:27017
> </config-property>
> <config-property name="Username">
> dv
> </config-property>
> <config-property name="Password">
> dv
> </config-property>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> Server log:
> 16:46:49,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "mongo-vdb.xml" (runtime-name: "mongo-vdb.xml")
> 16:46:49,809 DEBUG [org.teiid.RUNTIME] (MSC service thread 1-5) VDB mongo-vdb.xml has been parsed.
> 16:46:49,835 INFO [org.teiid.RUNTIME] (MSC service thread 1-1) TEIID50029 VDB mongo.1 model "importVDBSrcModel" metadata is currently being loaded. Start Time: 7/23/15 4:46 PM
> 16:46:49,869 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015859: Deployed "mongo-vdb.xml" (runtime-name : "mongo-vdb.xml")
> 16:46:50,626 WARN [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50036 VDB mongo.1 model "importVDBSrcModel" metadata failed to load. Reason:java.lang.NullPointerException: java.lang.NullPointerException
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.addTable(MongoDBMetadataProcessor.java:92)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:57)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:38)
> at org.teiid.translator.ExecutionFactory.getMetadata(ExecutionFactory.java:935) [teiid-api-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:73) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (TEIID-3329) Rationalize older spatial support with the new
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3329?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-3329 at 7/23/15 1:33 PM:
----------------------------------------------------------------
For the most part we would just want to promote the use of the ST_ functions over the oracle function forms, and don't see any consolidation what we want to do at this time.
For the mongodb logic we have something like:
mongo.geoWithin(CategoryName, 'Polygon', ((cast(1.0 as double), cast(2.0 as double)),(cast(3.0 as double), cast(4.0 as double))))
This could have just a geometry argument, which the translator would then convert to geojson (although I'm not sure how that would mesh with the BasicDBObjectBuilder logic) for example:
{code}
mongo.geoWithin(CategoryName, ST_GeomFromGeoJSON('{"coordinates":[[1,2],[3,4]],"type":"Polygon"}'))
{code}
was (Author: shawkins):
For the most part we would just want to promote the use of the ST_ functions over the oracle function forms, and don't see any consolidation what we want to do at this time.
For the mongodb logic we have something like:
mongo.geoWithin(CategoryName, 'Polygon', ((cast(1.0 as double), cast(2.0 as double)),(cast(3.0 as double), cast(4.0 as double))))
This could have just a geometry argument, which the translator would then convert to geojson (although I'm not sure how that would mesh with the BasicDBObjectBuilder logic) for example:
mongo.geoWithin(CategoryName, ST_GeomFromGeoJSON('{"coordinates":[[1,2],[3,4]],"type":"Polygon"}'))
> Rationalize older spatial support with the new
> ----------------------------------------------
>
> Key: TEIID-3329
> URL: https://issues.jboss.org/browse/TEIID-3329
> Project: Teiid
> Issue Type: Quality Risk
> Components: Misc. Connectors
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> MongoDB and Oracle had existing spatial support that should be updated to account for the new support if possible.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (TEIID-3329) Rationalize older spatial support with the new
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3329?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3329:
---------------------------------------
For the most part we would just want to promote the use of the ST_ functions over the oracle function forms, and don't see any consolidation what we want to do at this time.
For the mongodb logic we have something like:
mongo.geoWithin(CategoryName, 'Polygon', ((cast(1.0 as double), cast(2.0 as double)),(cast(3.0 as double), cast(4.0 as double))))
This could have just a geometry argument, which the translator would then convert to geojson (although I'm not sure how that would mesh with the BasicDBObjectBuilder logic) for example:
mongo.geoWithin(CategoryName, ST_GeomFromGeoJSON('{"coordinates":[[1,2],[3,4]],"type":"Polygon"}'))
> Rationalize older spatial support with the new
> ----------------------------------------------
>
> Key: TEIID-3329
> URL: https://issues.jboss.org/browse/TEIID-3329
> Project: Teiid
> Issue Type: Quality Risk
> Components: Misc. Connectors
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> MongoDB and Oracle had existing spatial support that should be updated to account for the new support if possible.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months