[JBoss JIRA] (TEIID-2408) statistics of teiid query queuing information
by Jack Ma (JIRA)
[ https://issues.jboss.org/browse/TEIID-2408?page=com.atlassian.jira.plugin... ]
Jack Ma reopened TEIID-2408:
----------------------------
Hi Ramesh:
I am trying to verify this issue at 8.3 teiid final release. When I try to retrieve the engineStatistics, I got following exception:
Caused by: java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.getChild(ModelValue.java:108)
at org.jboss.dmr.PropertyModelValue.getChild(PropertyModelValue.java:116)
at org.jboss.dmr.ModelNode.get(ModelNode.java:798)
at org.teiid.adminapi.impl.VDBMetadataMapper$EngineStatisticsMetadataMapper.unwrap(VDBMetadataMapper.java:1014)
at org.teiid.adminapi.impl.VDBMetadataMapper$EngineStatisticsMetadataMapper.unwrap(VDBMetadataMapper.java:973)
at org.teiid.adminapi.AdminFactory$AdminImpl.getList(AdminFactory.java:1389)
at org.teiid.adminapi.AdminFactory$AdminImpl.getDomainAwareList(AdminFactory.java:1376)
at org.teiid.adminapi.AdminFactory$AdminImpl.getEngineStats(AdminFactory.java:784)
By debugging a little bit of teiid source code:
at AdminFactory$AdminImpl.getList(ModelNode, MetadataMapper<T>), we try to from operationResult to create a list of node for each field of results. then to unwrap the each node individually. soat VDBMetadataMapper$EngineStatisticsMetadataMapper.unwrap(ModelNode), input ModelNode parameter only contains one field of engine statistic results each time, for example, it only has a node contains "Session-count", but teiid is trying to get all other engine statistics which does not exist in this individual node. So exception occurred.
Therefore I re-opened this issue. Please confirm it.
Thanks
Jack
> statistics of teiid query queuing information
> ---------------------------------------------
>
> Key: TEIID-2408
> URL: https://issues.jboss.org/browse/TEIID-2408
> Project: Teiid
> Issue Type: Feature Request
> Components: AdminApi
> Affects Versions: 8.2
> Reporter: Jack Ma
> Assignee: Ramesh Reddy
> Fix For: 8.3
>
>
> At currently version of teiid, there is no teiid queuing information available from either teiid api or log or jmx, like how many query plans are still in the waiting queue, how many are in the active queue etc. .Thinking those queuing information is pretty critical for performance tuning up,
> Based on the Ramesh's suggestion, creating this request for probably a statistics max water mark in the waiting queue, and average time spent in waiting queue etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (TEIID-2451) Break out VDB Translator Overrides and Models into a Separate Resource
by Ted Jones (JIRA)
Ted Jones created TEIID-2451:
--------------------------------
Summary: Break out VDB Translator Overrides and Models into a Separate Resource
Key: TEIID-2451
URL: https://issues.jboss.org/browse/TEIID-2451
Project: Teiid
Issue Type: Feature Request
Components: RHQ
Affects Versions: 8.3
Reporter: Ted Jones
Assignee: Ted Jones
Fix For: 8.4
Currently, models and translator overrides display and the VDB configuration page. If we break them out as a separate resource, they will display as folders under the VDB resource which will be cleaner than having everything on one tab.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (TEIID-2445) vdb.xml usability enhancements
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2445?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2445.
-----------------------------------
Resolution: Done
effectively replaced UseConnectorMetadata with cache-metadata and supports-multi-source-bindings with multisource and updated the release notes / docs appropriately.
> vdb.xml usability enhancements
> ------------------------------
>
> Key: TEIID-2445
> URL: https://issues.jboss.org/browse/TEIID-2445
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> Couple of usability enhancements need to be done on the -vdb.xml to make the intent clear
> UseConnectorMetadata=true/cached
> - The true case could be removed entirely. The notion of metadata caching could be handled by a model property and should probably be more baked into the MetadataRepository facility (such as passing the cached metadata in for update).
> supports-multi-source-bindings=true/false
> - Since we have mostly removed the binding terminology, it would make more sense to call this just multi-source or multisource (which is consistent with the multisource.columnName and addColumn properties). We could also automatically infer it to be true when there are multiple sources listed for a single model (which is currently an error case without this property) so that it would only be needed if you wanted a single source to appear as if it were a multisource model.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (TEIID-2449) Allow for a vdb zip to store ddl outside of the vdb.xml
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2449?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2449:
---------------------------------------
The initial check-in adds VDBResource instances available via the MetadataFactory.getVDBResources for use by metadata repositories. Another approach would be to make the resources available via the VDB, but that didn't seem appropriate given the remote usages.
A DDL-FILE repository was added that uses the metadata text to specify the location of the ddl file, which will be an absolute path relative to the root of the vdb zip.
The index logic was further refactored to remove unnecessary code, mostly related to update/save functionality and to remove the dependency on VirtualFile. Also converted the IndexMetadataStore/IndexMetadataRepository into a single IndexMetadataRepository class. This should address an issue where enterprise types from index vdbs are not be added into the metadatastore, since we were only setting the Schema.
> Allow for a vdb zip to store ddl outside of the vdb.xml
> -------------------------------------------------------
>
> Key: TEIID-2449
> URL: https://issues.jboss.org/browse/TEIID-2449
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Fix For: 8.4
>
>
> Our current vdb.xml design will include the ddl metadata string in-memory which is not desirable for large metadata sets. We should provide a built-in mechanism to relocate the metadata to separate files in a zip (which can also be a natural replacement for index files when the designer is ready).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (TEIID-2450) Like criteria with 'Z' before wildcards throw an exception
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2450?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2450:
---------------------------------------
> But there should be some reason for creating submap. I guess it's speed, am I right?
Yes the whole point is to avoid full scans when possible regardless of whether we're targeting a real table or a memory backed construct like the system tables.
> So it would be great to have that submap work right if it isn't a complex task.
It is working as intended.
> If you look at ASCII table you'll see that characters follow in such order:
Yes, I am aware of the character ordering. Here again it does not matter if if ^ _ etc. are initially included in the submap. What matters is that the partial prefix matching reduces the amount of the table that we scan.
> Like criteria with 'Z' before wildcards throw an exception
> ----------------------------------------------------------
>
> Key: TEIID-2450
> URL: https://issues.jboss.org/browse/TEIID-2450
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Paul Lysak
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> If query contains letter 'Z' before wildcard (for example, query contains following part: MY_COLUMN LIKE 'BAZ_BAR') then exception is thrown:
> Caused by: java.lang.IllegalArgumentException: fromKey > toKey
> at java.util.TreeMap$NavigableSubMap.<init>(TreeMap.java:1240)
> ...
> at org.teiid.dqp.internal.process.RecordTable.processQuery(RecordTable.java:189)
> ...
>
> The reason of the problem is following.
> BaseIndexInfo.processCriteria() in order to build "less then" conditon from LIKE increments the code of last character in condition prefix:
> this.addCondition(i, new Constant(prefix.substring(0, prefix.length() -1) + (char) (prefix.charAt(prefix.length()-1)+1)), CompareCriteria.LE);
> If prefix happens to end in uppercase letter 'Z' then after increment it becomes '['.
> But TempMetadataStore uses String.CaseInsensitiveComparator:
> public TempMetadataStore() {
> this(new TreeMap<String, TempMetadataID>(String.CASE_INSENSITIVE_ORDER));
> }
> And String API documentation clearly says that comparison is performed against lowercase versions. Therefore 'Z' is converted to 'z'.
> And later when trying to get subtree with lower bound = 'Z' and upper bound = '[' and exception is thrown because in fact 'z' is lesser then '['
> Other than this exception it also has another problem. If we do query MY_COLUMN LIKE 'BA@_BAR' then upper condition would be 'A' (next character after '@').
> But due to lowercase comparison it will be converted to 'a', so values like 'BAB_BAR', 'BAC_BAR', ... 'BA^_BAR' all would be returned because 'B', 'C', ..., '^' are between '@' and 'a'.
> I suggest either using case sensitive map (with prior conversion of all values to upper case) or converting values in BaseIndexInfo.processCriteria() into lower case.
> I also worry about CompareCriteria.LE in BaseIndexInfo.processCriteria(). Shouldn't it be strictly less? with less or equal when querying 'AAA_' you will get 'AAB_' values as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (TEIID-2450) Like criteria with 'Z' before wildcards throw an exception
by Paul Lysak (JIRA)
[ https://issues.jboss.org/browse/TEIID-2450?page=com.atlassian.jira.plugin... ]
Paul Lysak commented on TEIID-2450:
-----------------------------------
In practice I've only faced the problem with 'Z'. Other issues are merely hypotetical - what I've spotted from the code.
If there is some post-query check that eliminates items that don't satisfy LIKE condition then it should be OK.
But there should be some reason for creating submap. I guess it's speed, am I right?
So it would be great to have that submap work right if it isn't a complex task.
If you look at ASCII table you'll see that characters follow in such order:
... @ A B ... Y Z [ \ ] ^ _ ` a b ... y z { | } ~
I agree that B, C, ... Z will not get into submap with lowercase comparison, that was my mistake.
But characters [ \ ] ^ _ ` still will be there.
Thanks for your effort!
> Like criteria with 'Z' before wildcards throw an exception
> ----------------------------------------------------------
>
> Key: TEIID-2450
> URL: https://issues.jboss.org/browse/TEIID-2450
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Paul Lysak
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> If query contains letter 'Z' before wildcard (for example, query contains following part: MY_COLUMN LIKE 'BAZ_BAR') then exception is thrown:
> Caused by: java.lang.IllegalArgumentException: fromKey > toKey
> at java.util.TreeMap$NavigableSubMap.<init>(TreeMap.java:1240)
> ...
> at org.teiid.dqp.internal.process.RecordTable.processQuery(RecordTable.java:189)
> ...
>
> The reason of the problem is following.
> BaseIndexInfo.processCriteria() in order to build "less then" conditon from LIKE increments the code of last character in condition prefix:
> this.addCondition(i, new Constant(prefix.substring(0, prefix.length() -1) + (char) (prefix.charAt(prefix.length()-1)+1)), CompareCriteria.LE);
> If prefix happens to end in uppercase letter 'Z' then after increment it becomes '['.
> But TempMetadataStore uses String.CaseInsensitiveComparator:
> public TempMetadataStore() {
> this(new TreeMap<String, TempMetadataID>(String.CASE_INSENSITIVE_ORDER));
> }
> And String API documentation clearly says that comparison is performed against lowercase versions. Therefore 'Z' is converted to 'z'.
> And later when trying to get subtree with lower bound = 'Z' and upper bound = '[' and exception is thrown because in fact 'z' is lesser then '['
> Other than this exception it also has another problem. If we do query MY_COLUMN LIKE 'BA@_BAR' then upper condition would be 'A' (next character after '@').
> But due to lowercase comparison it will be converted to 'a', so values like 'BAB_BAR', 'BAC_BAR', ... 'BA^_BAR' all would be returned because 'B', 'C', ..., '^' are between '@' and 'a'.
> I suggest either using case sensitive map (with prior conversion of all values to upper case) or converting values in BaseIndexInfo.processCriteria() into lower case.
> I also worry about CompareCriteria.LE in BaseIndexInfo.processCriteria(). Shouldn't it be strictly less? with less or equal when querying 'AAA_' you will get 'AAB_' values as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (TEIID-2449) Allow for a vdb zip to store ddl outside of the vdb.xml
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2449?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2449:
---------------------------------------
The basic approach here will be to elevate the concept of the vdb resource map into a first class citizen that will be available during the metadata load. Then all special handling related to index metadata can be removed. However for backwards compatibility we'll probably have to assume that any vdb with indexes should assume that the indexmetadatarepository is the default (which is the current handling). A new metadata repository type "ddl-file" would need to be created that could be used in a zip to reference the appropriate zip file resource.
> Allow for a vdb zip to store ddl outside of the vdb.xml
> -------------------------------------------------------
>
> Key: TEIID-2449
> URL: https://issues.jboss.org/browse/TEIID-2449
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Fix For: 8.4
>
>
> Our current vdb.xml design will include the ddl metadata string in-memory which is not desirable for large metadata sets. We should provide a built-in mechanism to relocate the metadata to separate files in a zip (which can also be a natural replacement for index files when the designer is ready).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months