February 2016 - teiid-issues - Jboss List Archives

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3983?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3983. ----------------------------------- Resolution: Done Changed to look at the extension metadata for the status table. > 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 > Fix For: 9.0, 8.12.5, 8.13.2 > > > 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. > During the wait, when logging set to DEBUG, there appears regularly, apart from the logs about refreshing the mat view, this entry: > {code:plain} > [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 with state PROCESSING > [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 - processor blocked > {code} > The log appears in 'ttl' determined intervals, each time after materialized table loading related entries. > The thread mentioned is the one created after the original query execution was initiated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4001) Make error handling check for content type in OData4

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4001?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4001: --------------------------------------- I was seeing that we are assuming JSON even for the metadata fetch, which since it doesn't specify the format or the accepts header can return a non json response. And in general if there is a higher level server error, then you are likely to get an xhtml page which the atom logic can handle, so it seems good to have the handling there. > Make error handling check for content type in OData4 > ---------------------------------------------------- > > Key: TEIID-4001 > URL: https://issues.jboss.org/browse/TEIID-4001 > Project: Teiid > Issue Type: Quality Risk > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > Unless json is specifically requested errors are typically returned in atom. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4001) Make error handling check for content type in OData4

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4001?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4001: ------------------------------------- Right now the specification does not mandate any default format, right now Olingo has chosen JSON as the default format, I think we should honor that for the errors too. > Make error handling check for content type in OData4 > ---------------------------------------------------- > > Key: TEIID-4001 > URL: https://issues.jboss.org/browse/TEIID-4001 > Project: Teiid > Issue Type: Quality Risk > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > Unless json is specifically requested errors are typically returned in atom. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4001) Make error handling check for content type in OData4

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4001?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4001. ----------------------------------- Resolution: Done Added atom handling as well. > Make error handling check for content type in OData4 > ---------------------------------------------------- > > Key: TEIID-4001 > URL: https://issues.jboss.org/browse/TEIID-4001 > Project: Teiid > Issue Type: Quality Risk > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0 > > > Unless json is specifically requested errors are typically returned in atom. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4001) Make error handling check for content type in OData4

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4001: ------------------------------------- Summary: Make error handling check for content type in OData4 Key: TEIID-4001 URL: https://issues.jboss.org/browse/TEIID-4001 Project: Teiid Issue Type: Quality Risk Components: Misc. Connectors Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.0 Unless json is specifically requested errors are typically returned in atom. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

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: --------------------------------------- The initial commit of the code is in for 9.0 alpha2. There will probably still be refinements. There will also need to be doc updates and sub-tasks addressed. > 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)

8 years, 2 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3983?page=com.atlassian.jira.plugin... ] Steven Hawkins reopened TEIID-3983: ----------------------------------- > 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 > Fix For: 9.0, 8.12.5, 8.13.2 > > > 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. > During the wait, when logging set to DEBUG, there appears regularly, apart from the logs about refreshing the mat view, this entry: > {code:plain} > [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 with state PROCESSING > [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 - processor blocked > {code} > The log appears in 'ttl' determined intervals, each time after materialized table loading related entries. > The thread mentioned is the one created after the original query execution was initiated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3996) SAP HANA materialization: MATVIEW_ONERROR_ACTION set to WAIT problem

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3996?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3996. ----------------------------------- Resolution: Duplicate Issue See TEIID-3983 > SAP HANA materialization: MATVIEW_ONERROR_ACTION set to WAIT problem > -------------------------------------------------------------------- > > Key: TEIID-3996 > URL: https://issues.jboss.org/browse/TEIID-3996 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.x > Reporter: Jan Stastny > Assignee: Steven Hawkins > > When using materialization wit SAP HANA datasource, a problem emerges when "teiid_rel:MATVIEW_ONERROR_ACTION" 'WAIT' is defined for the materialized view. > The query which initiates matview's loading doesn't wait for its completion, thus returns stale data (empty resultset in case of the initial invocation). > Materialized view definition: > {code:sql} > CREATE VIEW external_long_ttl ( > customer_id integer NOT NULL, > total_amount integer > ) OPTIONS ( > MATERIALIZED 'TRUE', > UPDATABLE 'FALSE', > MATERIALIZED_TABLE 'Source.JSTASTNY.dv_matviews_mat_view', > "teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true', > "teiid_rel:MATVIEW_STATUS_TABLE" 'Source.JSTASTNY.dv_matviews_statustable', > "teiid_rel:ON_VDB_START_SCRIPT" 'MERGE INTO dv_matviews_check_table(id,vdb_create) SELECT id, vdb_create+1 FROM dv_matviews_check_table WHERE id=''external_long_ttl'';', > "teiid_rel:ON_VDB_DROP_SCRIPT" 'MERGE INTO dv_matviews_check_table(id,vdb_drop) SELECT id, vdb_drop+1 FROM dv_matviews_check_table WHERE id=''external_long_ttl'';', > "teiid_rel:MATVIEW_LOAD_SCRIPT" 'INSERT INTO dv_matviews_mat_view_stage(customer_id,total_amount) SELECT CONVERT(c.id,integer) AS customer_id, CONVERT(SUM(o.amount),integer) AS total_amount FROM dv_matviews_customers c INNER JOIN dv_matviews_orders o ON c.id = o.customer_id GROUP BY c.id;', > "teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'exec Source.native(''truncate table dv_matviews_mat_view_stage'');MERGE INTO dv_matviews_check_table(id,before_load) SELECT id, before_load+1 FROM dv_matviews_check_table WHERE id=''external_long_ttl'';', > "teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'exec Source.native(''RENAME TABLE dv_matviews_mat_view_stage TO dv_matviews_mat_view_temp'');exec Source.native(''RENAME TABLE dv_matviews_mat_view TO dv_matviews_mat_view_stage'');exec Source.native(''RENAME TABLE dv_matviews_mat_view_temp TO dv_matviews_mat_view'');MERGE INTO dv_matviews_check_table(id,after_load) SELECT id, after_load+1 FROM dv_matviews_check_table WHERE id=''external_long_ttl'';', > "teiid_rel:MATVIEW_ONERROR_ACTION" 'WAIT', > "teiid_rel:MATVIEW_TTL" 20000 > ) AS SELECT CONVERT(c.id,integer) AS customer_id, CONVERT(SUM(o.amount),integer) AS total_amount FROM dv_matviews_customers c INNER JOIN dv_matviews_orders o ON c.id = o.customer_id GROUP BY c.id; > {code} > Query performed: > {code:sql} > SELECT * FROM external_long_ttl; > {code} > Reproducer: > {code:java} > Statement statement = connection.createStatement(); > // invoke initial load, won't return loaded data even though it should > ResultSet rs1 = statement.executeQuery("SELECT * FROM external_long_ttl;"); > Assert.assertFalse(rs1.next()); > // wait explicitly for the loading to finish > Thread.sleep(7000); > // repeat the query, to get the data after load finished > ResultSet rs2 = statement.executeQuery("SELECT * FROM external_long_ttl;"); > Assert.assertTrue(rs2.next()); > . > . > . > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3983?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3983: --------------------------------------- Yes, I didn't account for that being a metadata property. I'll add another commit. > 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 > Fix For: 9.0, 8.12.5, 8.13.2 > > > 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. > During the wait, when logging set to DEBUG, there appears regularly, apart from the logs about refreshing the mat view, this entry: > {code:plain} > [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 with state PROCESSING > [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 - processor blocked > {code} > The log appears in 'ttl' determined intervals, each time after materialized table loading related entries. > The thread mentioned is the one created after the original query execution was initiated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

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

by Jan Stastny (JIRA)

[ https://issues.jboss.org/browse/TEIID-3983?page=com.atlassian.jira.plugin... ] Jan Stastny edited comment on TEIID-3983 at 2/25/16 4:59 AM: ------------------------------------------------------------- [~shawkins] Commit 88fa78d doesn't respect property "teiid_rel:MATVIEW_STATUS_TABLE". There is table name 'status' hardcoded. See https://github.com/teiid/teiid/blob/master/engine/src/main/java/org/teiid... . If I create a status table with name 'status', it works as expected. Thus replacing of 'status' table name with "teiid_rel:MATVIEW_STATUS_TABLE" property value should fix the issue. was (Author: jstastny): [~shawkins] Commit 88fa78d doesn't respect property "teiid_rel:MATVIEW_STATUS_TABLE". There is table name 'status' hardcoded. See https://github.com/teiid/teiid/blob/master/engine/src/main/java/org/teiid... . > 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 > Fix For: 9.0, 8.12.5, 8.13.2 > > > 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. > During the wait, when logging set to DEBUG, there appears regularly, apart from the logs about refreshing the mat view, this entry: > {code:plain} > [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 with state PROCESSING > [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 - processor blocked > {code} > The log appears in 'ttl' determined intervals, each time after materialized table loading related entries. > The thread mentioned is the one created after the original query execution was initiated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2016