[JBoss JIRA] (TEIID-3982) BlockedException throw twice for each Query
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3982?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3982.
-----------------------------------
Fix Version/s: (was: 9.x)
Resolution: Rejected
The confusion here is that the blockedexception is typically a static instance. This is to minimize the creation of stacktrace details for every time that it is thrown.
> 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
>
> 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)
8 years, 10 months
[JBoss JIRA] (TEIID-3215) External Materialization ON_VDB_START_SCRIPT invocation issues
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-3215?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-3215:
------------------------------------
Not the same issue, I am sorry, I shouldn't have reopened this issue.
> External Materialization ON_VDB_START_SCRIPT invocation issues
> --------------------------------------------------------------
>
> Key: TEIID-3215
> URL: https://issues.jboss.org/browse/TEIID-3215
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Labels: Final
> Fix For: 8.7.1, 8.9
>
> Attachments: mat-views-vdb.xml
>
>
> With materialized view I have set teiid_rel:ON_VDB_START_SCRIPT property for the external matview table. (Simple query to increment a column in table to count invocations.)
> Invocation of the script is dependent upon the way the vdb is deployed. The first case (A) doesn't invoke the script, the second (B) does.
> A - 1. Copy the vdbname-vdb.xml into deployments folder
> 2. Start the server
> B - 1. Start the server
> 2. Copy the vdbname-vdb.xml into deployments folder
> That means that after server stop (maintenance) the script is not invoked on start, which can cause problems when the script is used to initialize running environment (clear table, create temporary table,...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (TEIID-3215) External Materialization ON_VDB_START_SCRIPT invocation issues
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-3215?page=com.atlassian.jira.plugin... ]
Jan Stastny reopened TEIID-3215:
--------------------------------
Reproduced the issue again with version 8.12.5
> External Materialization ON_VDB_START_SCRIPT invocation issues
> --------------------------------------------------------------
>
> Key: TEIID-3215
> URL: https://issues.jboss.org/browse/TEIID-3215
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Labels: Final
> Fix For: 8.7.1, 8.9
>
> Attachments: mat-views-vdb.xml
>
>
> With materialized view I have set teiid_rel:ON_VDB_START_SCRIPT property for the external matview table. (Simple query to increment a column in table to count invocations.)
> Invocation of the script is dependent upon the way the vdb is deployed. The first case (A) doesn't invoke the script, the second (B) does.
> A - 1. Copy the vdbname-vdb.xml into deployments folder
> 2. Start the server
> B - 1. Start the server
> 2. Copy the vdbname-vdb.xml into deployments folder
> That means that after server stop (maintenance) the script is not invoked on start, which can cause problems when the script is used to initialize running environment (clear table, create temporary table,...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[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 updated TEIID-3983:
-------------------------------
Description:
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.
was:
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.
> 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.
> 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, 10 months
[JBoss JIRA] (TEIID-3982) BlockedException throw twice for each Query
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3982?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3982:
------------------------------------
The Stack track hints BlockedException throw while QueryProcessor init, But this *Strange*, in my debug, the Exception throw in BatchCollector's collectTuples(), in processMore() method.
process() -> processMore() -> collector.collectTuples()
QueryProcessor init happens in processNew(), which happens before processMore(), each request only executed 1 time, and not error happen.
> 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)
8 years, 10 months
[JBoss JIRA] (TEIID-3983) External Materialization MATVIEW_ONERROR_ACTION WAIT problem
by Jan Stastny (JIRA)
Jan Stastny created TEIID-3983:
----------------------------------
Summary: 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)
8 years, 10 months
[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)
8 years, 10 months