September 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Closed: (TEIID-607) Connectors with invalid connection properties should show Source Unavailable at startup

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-607?page=com.atlassian.jira.plug... ] Steven Hawkins closed TEIID-607. -------------------------------- > Connectors with invalid connection properties should show Source Unavailable at startup > --------------------------------------------------------------------------------------- > > Key: TEIID-607 > URL: https://jira.jboss.org/jira/browse/TEIID-607 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0 > Environment: MMServer: Fedora 8 Kernel 2.6.26.6-49.fc8 > Connector: Oracle JDBC Connector > Reporter: Larry O'Leary > Fix For: 6.2.0 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > If invalid connection properties are used in a connector binding the connector status shows "Running" at startup of the connector. When the first query is executed against the MMSystem that needs this connector an exception is thrown indicating that the connector wasn't found. This is due to the connector state changing to "Data Source Unavailable". > Although this is the expected behavior it is very mis-leading to the administrator after creating/adding a new connector or bouncing the system. The MMConsole gives the appearance that everything is okay until users actually start running queries. > What should be occurring is the current behavior and if Data Source Monitoring is enabled on the connector we should then check the data source available during connector startup. In other words, start the monitor thread with a timer of 0 instead a timer of monitoring interval. The idea is to show the connector as "Data Source Unavailable" at connector startup if the source isn't can't be reached due to invalid connection properties. > TEST: > To test this issue you simply need to have a connector deployed to a running MMSystem and verify that it is actually starting correctly with correct properties (ie verify you can run queries using this connector). > Now, change the password on the connector to something that is invalid. Stop and then start the connector. The connector will show a "Running" state yet as soon as you execute the query the query will fail and the status of the connector will change to "Source Unavailable". > EXPECTED RESULT: > When you start a connector using an invalid password (or other connection type property like SID, DatabaseName, etc) the connector state should immediately reflect "Data Source Unavailable". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-664) Add "membership" service

by Ramesh Reddy (JIRA)

Add "membership" service ------------------------ Key: TEIID-664 URL: https://jira.jboss.org/jira/browse/TEIID-664 Project: Teiid Issue Type: Sub-task Components: Embedded, Query Engine, Server Reporter: Ramesh Reddy Assignee: Steven Hawkins Priority: Critical Fix For: 6.2.0 Add the "membership" service. Should support implementations for LDAP and File based. Also, user should have an option to turn this OFF through configuration, which resembles with current embedded's functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

2
3
0 / 0

[JBoss JIRA] Closed: (TEIID-128) Consider replacing homegrown XML-Relational doc cache implementation with JBoss Cache or other standard implementation

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-128?page=com.atlassian.jira.plug... ] Steven Hawkins closed TEIID-128. -------------------------------- > Consider replacing homegrown XML-Relational doc cache implementation with JBoss Cache or other standard implementation > ---------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-128 > URL: https://jira.jboss.org/jira/browse/TEIID-128 > Project: Teiid > Issue Type: Quality Risk > Components: XML Connector > Affects Versions: 7.x > Reporter: Greg Haber > Assignee: John Doyle > Priority: Minor > Fix For: 6.1.0 > > > My understanding is that the document cache implementation in the XML-Relational connector is a homegrown implementation. Homegrown = more code to maintain and better chance of us hitting major issues like JBEDSP-834. Plus AFAIK this homegrown cache implementation locks the whole cache even on read operations which I suspect is going to introduce scaling problems (in fact I think we actually experienced this at a customer with 5.0SP2 but we were unable to conclusively determine that that was the cause of problems we saw then). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (TEIID-259) Create Teiid Server Kit

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-259?page=com.atlassian.jira.plug... ] Steven Hawkins closed TEIID-259. -------------------------------- > Create Teiid Server Kit > ----------------------- > > Key: TEIID-259 > URL: https://jira.jboss.org/jira/browse/TEIID-259 > Project: Teiid > Issue Type: Task > Components: Build/Kits > Affects Versions: 6.0.0 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Blocker > Fix For: 6.2.0 > > > Build a server kit and corresponding configuration installer for the server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (TEIID-339) Push down aggragate and distinct through union

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-339?page=com.atlassian.jira.plug... ] Steven Hawkins closed TEIID-339. -------------------------------- > Push down aggragate and distinct through union > ---------------------------------------------- > > Key: TEIID-339 > URL: https://jira.jboss.org/jira/browse/TEIID-339 > Project: Teiid > Issue Type: Task > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Li Liang > Assignee: Steven Hawkins > Fix For: 6.2.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > This is related to case 6652 and case 6653. It improves performance to push down aggragate and distinct through union. If this is done before 5.5.3 release, we will consider pulling the logics back to 5.5.3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-162) Delete and update support in temp table

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-162?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-162. ---------------------------------- Resolution: Done The implementation creates a new tuple source as the target for the update. This will have poor performance for large temp tables. > Delete and update support in temp table > --------------------------------------- > > Key: TEIID-162 > URL: https://jira.jboss.org/jira/browse/TEIID-162 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.3.0 > > > Defect Tracker #23925: Delete and update are currently not supported in temp table. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-165) Connector support for more converts

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-165?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-165. ---------------------------------- Resolution: Won't Fix It is unlikely that there would be any benefit in supporting the pushdown of string to clob or even sting to xml. If the conversion is being performed in the top level projection, it's just as easy for Teiid to apply the transformation. Also the client can fetch the results as clob or xml even if the value is a string. Marking as won't fix. > Connector support for more converts > ----------------------------------- > > Key: TEIID-165 > URL: https://jira.jboss.org/jira/browse/TEIID-165 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 7.x > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.3.0 > > > Defect Tracker #24822: Connector support for more converts (from object, clob, xml). Query changes are needed to remove the check from CapabilitiesUtil that is preventing the push down. Additionally defect 15144 should be worked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-181) Allow connectors to request replanning of source query by throwing an exception

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-181?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-181: --------------------------------- Fix Version/s: (was: 7.0) Changing back to an unassigned fix version. Unless we intend to move more fully down the path of SQL MED, then we'll probably just reject this issue for now. > Allow connectors to request replanning of source query by throwing an exception > ------------------------------------------------------------------------------- > > Key: TEIID-181 > URL: https://jira.jboss.org/jira/browse/TEIID-181 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Reporter: Greg Haber > Assignee: Steven Hawkins > Priority: Minor > > In FEDERATE-126 more granular connector capabilities were requested, for supporting sources that don't follow traditional relational capability patterns (especially SFDC). > The level of effort for such a request is presumably fairly high for the DQP component, since it needs to have additional logic added to understand the new capability and to modify the planning process to take them into account. > It occurred to me that a general purpose backup mechanism would be for connectors to have the ability after getting a query they couldn't handle, to throw a new type of exception (perhaps ReplanRequestException), which would contain information about what connector capabilities should be excluded from the replanning process. Then the planner would come up with a new plan, and make new source query/queries based off that new plan. > For example take the case of SFDC, which handles outer joins (left or right, but not full) but not inner joins (and for the sake of argument say that FEDERATE-126 and FEDERATE-114 were not implemented). The SFDC connector gets sent a query with an inner join. It then throws an exception requesting a replan, this time with no join pushdown. Then the planner replans this as without join pushdown, and resubmits the query (or in many cases multiple queries). > Now, one big question here is, does replanning mean replanning the entire federated query, or just redoing that one source query? The former would give a more efficient overall plan, but it may be too late to do this (other connectors may already be at work). For the former to work, I would think we would need to have an additional step in the connector framework to run the proposed query plan by all the connectors before actually executing anything, which would be additional overhead on all queries, not the small subset for which this problem exists. So maybe the latter (redoing that one source query) is the only reasonable alternative. > A workaround with similar results is FEDERATE-114 style stuff (tell the consumer what was wrong, and ask them to override connector capabilities in a new query. But that has the same general inefficiency of an automatic replanning of the entire federated query. So it would not be as nice as replanning just one source query. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-181) Allow connectors to request replanning of source query by throwing an exception

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-181?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIID-181: ------------------------------- Fix Version/s: 7.0 > Allow connectors to request replanning of source query by throwing an exception > ------------------------------------------------------------------------------- > > Key: TEIID-181 > URL: https://jira.jboss.org/jira/browse/TEIID-181 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Reporter: Greg Haber > Assignee: Steven Hawkins > Priority: Minor > Fix For: 7.0 > > > In FEDERATE-126 more granular connector capabilities were requested, for supporting sources that don't follow traditional relational capability patterns (especially SFDC). > The level of effort for such a request is presumably fairly high for the DQP component, since it needs to have additional logic added to understand the new capability and to modify the planning process to take them into account. > It occurred to me that a general purpose backup mechanism would be for connectors to have the ability after getting a query they couldn't handle, to throw a new type of exception (perhaps ReplanRequestException), which would contain information about what connector capabilities should be excluded from the replanning process. Then the planner would come up with a new plan, and make new source query/queries based off that new plan. > For example take the case of SFDC, which handles outer joins (left or right, but not full) but not inner joins (and for the sake of argument say that FEDERATE-126 and FEDERATE-114 were not implemented). The SFDC connector gets sent a query with an inner join. It then throws an exception requesting a replan, this time with no join pushdown. Then the planner replans this as without join pushdown, and resubmits the query (or in many cases multiple queries). > Now, one big question here is, does replanning mean replanning the entire federated query, or just redoing that one source query? The former would give a more efficient overall plan, but it may be too late to do this (other connectors may already be at work). For the former to work, I would think we would need to have an additional step in the connector framework to run the proposed query plan by all the connectors before actually executing anything, which would be additional overhead on all queries, not the small subset for which this problem exists. So maybe the latter (redoing that one source query) is the only reasonable alternative. > A workaround with similar results is FEDERATE-114 style stuff (tell the consumer what was wrong, and ask them to override connector capabilities in a new query. But that has the same general inefficiency of an automatic replanning of the entire federated query. So it would not be as nice as replanning just one source query. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-662) Solidify the AdminAPI

by Van Halbert (JIRA)

Solidify the AdminAPI --------------------- Key: TEIID-662 URL: https://jira.jboss.org/jira/browse/TEIID-662 Project: Teiid Issue Type: Task Components: AdminApi, Server Affects Versions: 6.2.0 Reporter: Van Halbert Assignee: Steven Hawkins To solidify the adminapi, it needs to be cleaned up (remove the subsystem), ensuring its clear whats used for monitoring versus configuration, making sure JOPR is supported and fixing/removing unused variables and documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues September 2009