February 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3983) External Materialization MATVIEW_ONERROR_ACTION WAIT problem

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3983?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-3983: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1309582 Bugzilla Update: Perform > External Materialization MATVIEW_ONERROR_ACTION WAIT problem > ------------------------------------------------------------ > > Key: TEIID-3983 > URL: https://issues.jboss.org/browse/TEIID-3983 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.5 > Reporter: Jan Stastny > Assignee: Steven Hawkins > > When using "teiid_rel:MATVIEW_ONERROR_ACTION" 'WAIT' option in materialized view definition, there's problem with blocked request. > The blocked request is the one, that triggered the materialized view's loading (first query on the defined materialized view). After such request, one can observe, that the query execution doesn't end, but hangs. > Meanwhile while examining the contents of 'status' table in the underlying database, the LoadNumber column's value increases regularly according to the defined ttl. Moreover the 'LOADSTATE' column changes from LOADING to LOADED in similar manner. The materialized table is populated with correct data. From this I assume, materialization is set up correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3982) BlockedException throw twice for each Query

by Kylin Soong (JIRA)

Kylin Soong created TEIID-3982: ---------------------------------- Summary: BlockedException throw twice for each Query Key: TEIID-3982 URL: https://issues.jboss.org/browse/TEIID-3982 Project: Teiid Issue Type: Quality Risk Components: Query Engine Affects Versions: 9.x Reporter: Kylin Soong Assignee: Steven Hawkins Fix For: 9.x I have met a question while I was runing [embedded-portfolio](https://github.com/teiid/teiid-embedded-examples/tree... example, Even the Query can get result correctly, but each query can cause BlockedException throw 2 times, a DEBUG log be recorded 2 times for each query: {code} 2016-02-18 14:58 754 DEBUG [org.teiid.PROCESSOR] (main) Request Thread 2Py78gPmtfcm.0 - processor blocked 2016-02-18 14:58 930 DEBUG [org.teiid.PROCESSOR] (main) Request Thread 2Py78gPmtfcm.0 - processor blocked {code} The Exception stack trace in my test looks {code} org.teiid.common.buffer.BlockedException at org.teiid.common.buffer.BlockedException.<clinit>(BlockedException.java:39) at org.teiid.query.processor.QueryProcessor.<clinit>(QueryProcessor.java:58) at org.teiid.dqp.internal.process.Request.createProcessor(Request.java:334) at org.teiid.dqp.internal.process.Request.processRequest(Request.java:465) at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:633) at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:333) at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:271) at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:306) at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:180) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:260) at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:178) at com.sun.proxy.$Proxy11.executeRequest(Unknown Source) at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:670) at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:536) at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1073) at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:323) at org.teiid.example.util.JDBCUtils.execute(JDBCUtils.java:85) at org.teiid.test.embedded.process.TeiidEmbeddedPortfolioProcess.main(TeiidEmbeddedPortfolioProcess.java:58) {code} h3. Further investigation As [1], around line 350, {code} } catch (BlockedException e) { e.printStackTrace(); if (LogManager.isMessageToBeRecorded(LogConstants.CTX_DQP, MessageLevel.DETAIL)) { LogManager.logDetail(LogConstants.CTX_DQP, "Request Thread", requestID, "- processor blocked"); //$NON-NLS-1$ //$NON-NLS-2$ } if (e == BlockedException.BLOCKED_ON_MEMORY_EXCEPTION || e instanceof ExpiredTimeSliceException) { //requeue this.moreWork(); } } {code} Why each query need block processor 2 times? [1] https://github.com/teiid/teiid/blob/master/engine/src/main/java/org/teiid... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-2476) Exclude hidden tables/columns from metadata

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2476?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2476: --------------------------------------- > I know that is separate from this issue, but I can log that. If you hide the system tables, then DatabaseMetaData, ODBC metadata (which is needed even for just query execution), and even some geospatial logic won't work. So allowing them to be hidden would be a somewhat extreme case. > As per this issue, if we implement at DatabaseMetadata does't that differ with System metadata? DatabaseMetaData uses queries and some additional logic against the system metadata. I'm just saying that working this at the DatabaseMetaData layer is simpler. For consistency we'll have to implement this at the system table level and redo any of the materialization above. > Exclude hidden tables/columns from metadata > ------------------------------------------- > > Key: TEIID-2476 > URL: https://issues.jboss.org/browse/TEIID-2476 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Driver, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > We should offer or possibly default to filtering tables/columns that can not accessed out of the user metadata. This should be done on the server side - however given the reuse we have of the system tables for example for materialized pg catalog queries - it is easier to add filters to the DatabaseMetadata (and ideally pg) metadata queries. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-2476) Exclude hidden tables/columns from metadata

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2476?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2476: ------------------------------------- Along these lines few days someone asked me if they could design data roles to prohibit the access to the system tables, as they did not wanted them to be exposed to the client. I know that is separate from this issue, but I can log that. As per this issue, if we implement at DatabaseMetadata does't that differ with System metadata? > Exclude hidden tables/columns from metadata > ------------------------------------------- > > Key: TEIID-2476 > URL: https://issues.jboss.org/browse/TEIID-2476 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Driver, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > We should offer or possibly default to filtering tables/columns that can not accessed out of the user metadata. This should be done on the server side - however given the reuse we have of the system tables for example for materialized pg catalog queries - it is easier to add filters to the DatabaseMetadata (and ideally pg) metadata queries. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3981) Salesforce-34 connector dependency on "com.force.api" is wrong

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3981?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-3981. --------------------------------- Resolution: Done > Salesforce-34 connector dependency on "com.force.api" is wrong > -------------------------------------------------------------- > > Key: TEIID-3981 > URL: https://issues.jboss.org/browse/TEIID-3981 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.13, 9.0 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 9.0, 8.13.2 > > > connector-salesforce-34 depends on connector-salesforce, which depends on translator-salesforce that depends on com.force.api.22 > This need to be corrected through exclusions in the pom.xml. I believe the Teiid kit is fine, but will need to be double checked. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3981) Salesforce-34 connector dependency on "com.force.api" is wrong

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-3981: ----------------------------------- Summary: Salesforce-34 connector dependency on "com.force.api" is wrong Key: TEIID-3981 URL: https://issues.jboss.org/browse/TEIID-3981 Project: Teiid Issue Type: Bug Components: Misc. Connectors Affects Versions: 8.13, 9.0 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 9.0, 8.13.2 connector-salesforce-34 depends on connector-salesforce, which depends on translator-salesforce that depends on com.force.api.22 This need to be corrected through exclusions in the pom.xml. I believe the Teiid kit is fine, but will need to be double checked. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3980) NPE with Salesforce retrieve query and no matching entity

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3980?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3980. ----------------------------------- Resolution: Done Added a null check. > NPE with Salesforce retrieve query and no matching entity > --------------------------------------------------------- > > Key: TEIID-3980 > URL: https://issues.jboss.org/browse/TEIID-3980 > Project: Teiid > Issue Type: Bug > Components: Salesforce Connector > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5, 8.13.2 > > > A query such as: > select name, id from BusinessProcess where id = <does not exist> > will result in an NPE since the retrieve call returns a null record for each id that doesn't match. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-903) Replace fakemetadata with actual metadata classes

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-903?page=com.atlassian.jira.plugin.... ] Steven Hawkins resolved TEIID-903. ---------------------------------- Fix Version/s: 7.5 7.4.1 (was: 9.0) Resolution: Done Marking as resolved. There is a separate issue covering temp metadata - which is a much larger issues as the tempmetadataid logic is intertwined in the engine. > Replace fakemetadata with actual metadata classes > ------------------------------------------------- > > Key: TEIID-903 > URL: https://issues.jboss.org/browse/TEIID-903 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Affects Versions: 8.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 7.5, 7.4.1 > > > Temp and fakemetadata are redundant with the core metadata logic. Removing fakemetadata especially would help clean up testing code and increase coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-903) Replace fakemetadata with actual metadata classes

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-903?page=com.atlassian.jira.plugin.... ] Steven Hawkins updated TEIID-903: --------------------------------- Summary: Replace fakemetadata with actual metadata classes (was: Replace temp and fakemetadata with actual metadata classes) > Replace fakemetadata with actual metadata classes > ------------------------------------------------- > > Key: TEIID-903 > URL: https://issues.jboss.org/browse/TEIID-903 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Affects Versions: 8.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > Temp and fakemetadata are redundant with the core metadata logic. Removing fakemetadata especially would help clean up testing code and increase coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-903) Replace temp and fakemetadata with actual metadata classes

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-903?page=com.atlassian.jira.plugin.... ] Ramesh Reddy commented on TEIID-903: ------------------------------------ Is this something Kylin can help with? > Replace temp and fakemetadata with actual metadata classes > ---------------------------------------------------------- > > Key: TEIID-903 > URL: https://issues.jboss.org/browse/TEIID-903 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Affects Versions: 8.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > Temp and fakemetadata are redundant with the core metadata logic. Removing fakemetadata especially would help clean up testing code and increase coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2016