[JBoss JIRA] (TEIID-4776) Issues with array type metadata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4776?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4776:
----------------------------------
Summary: Issues with array type metadata (was: Issues with array type metadta)
> Issues with array type metadata
> -------------------------------
>
> Key: TEIID-4776
> URL: https://issues.jboss.org/browse/TEIID-4776
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0.6, 9.3, 9.2.1, 9.1.4
>
>
> If cached metadata (typically from Designer) is used, then on cached usage our logic to use the canonical datatype reference will reset the array dimension to 0 on array type columns.
> There is also an issue with Designer vdbs in that an array type cannot be conveyed as we are only looking at the datatype uuid and not at the runtime type name, which would contain the array dimensions.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4776) Issues with array type metadta
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4776:
-------------------------------------
Summary: Issues with array type metadta
Key: TEIID-4776
URL: https://issues.jboss.org/browse/TEIID-4776
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.0.6, 9.3, 9.2.1, 9.1.4
If cached metadata (typically from Designer) is used, then on cached usage our logic to use the canonical datatype reference will reset the array dimension to 0 on array type columns.
There is also an issue with Designer vdbs in that an array type cannot be conveyed as we are only looking at the datatype uuid and not at the runtime type name, which would contain the array dimensions.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4595) Wrong pushdown of several spatial functions to Oracle
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4595?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4595:
---------------------------------
Fix Version/s: 8.12.10.6_3
> Wrong pushdown of several spatial functions to Oracle
> -----------------------------------------------------
>
> Key: TEIID-4595
> URL: https://issues.jboss.org/browse/TEIID-4595
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.12.x
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Fix For: 9.1.2, 9.2, 8.12.10.6_3
>
>
> There are several geospatial functions that are wrongly pushed down to oracle
> # {{ST_DISTANCE}} is pushed as {{SDO_GEOM.DISTANCE}} which does not exist, should be {{SDO_GEOM.SDO_DISTANCE}}. This results in runtime error.
> # {{ST_CROSSES}} and {{ST_OVERLAPS}} are both pushed as {{SDO_RELATE}} with mask {{"overlapbydisjoint"}} which does not exists, should be {{"overlapbdydisjoint"}} (sic} for {{ST_CROSSES}} and {{"overlapbdyintersect"}} for {{ST_OVERLAPS}}. This results in {{false}} being returned for all calls to the two functions
> # Using {{ST_DISJOINT}} in the select clause (but not in criteria) results in the following error when evaluating to true:
> {noformat}
> org.teiid.jdbc.TeiidSQLException: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 SpatialModel: 99999 Unexpected exception while translating results: Fail to convert to internal representation
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
> at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:706)
> at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:64)
> at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:545)
> at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135)
> at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40)
> at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79)
> at org.teiid.net.socket.SocketServerInstanceImpl.receivedMessage(SocketServerInstanceImpl.java:268)
> at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:306)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:98)
> at com.sun.proxy.$Proxy18.read(Unknown Source)
> at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:405)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:554)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1060)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:323)
> at org.jboss.bqt.framework.AbstractQuery.execute(AbstractQuery.java:208)
> at org.jboss.bqt.client.testcase.ProcessResults.executeTest(ProcessResults.java:280)
> at org.jboss.bqt.client.testcase.ProcessResults.runTestCase(ProcessResults.java:166)
> at org.jboss.bqt.client.TestClient.runScenario(TestClient.java:209)
> at org.jboss.bqt.client.TestClient.runTest(TestClient.java:132)
> at org.jboss.bqt.client.TestClient.runTest(TestClient.java:113)
> at org.jboss.qe.bqt.BQTHelper.startTest(BQTHelper.java:59)
> at org.jboss.dv.test.bqt.Utils.runScenarioTest(Utils.java:185)
> at org.jboss.dv.test.bqt.TestPassRDBMS.testRdbms(TestPassRDBMS.java:210)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86)
> at org.testng.internal.MethodInvocationHelper$1.runTestMethod(MethodInvocationHelper.java:197)
> at org.jboss.qe.DVQETestListener.run(DVQETestListener.java:266)
> at org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:209)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:820)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1128)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
> at org.testng.TestRunner.privateRun(TestRunner.java:782)
> at org.testng.TestRunner.run(TestRunner.java:632)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
> at org.testng.SuiteRunner.run(SuiteRunner.java:268)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
> at org.testng.TestNG.run(TestNG.java:1064)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:70)
> at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:108)
> at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:111)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
> Caused by: org.teiid.core.TeiidProcessingException: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 SpatialModel: 99999 Unexpected exception while translating results: Fail to convert to internal representation
> at org.teiid.dqp.internal.process.DataTierTupleSource.exceptionOccurred(DataTierTupleSource.java:401)
> at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:161)
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:391)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.teiid.core.TeiidException: 99999 Remote org.teiid.translator.TranslatorException: 99999 Unexpected exception while translating results: Fail to convert to internal representation
> at org.teiid.translator.jdbc.JDBCQueryExecution.next(JDBCQueryExecution.java:351)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:436)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:236)
> at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy47.more(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> ... 6 more
> Caused by: java.sql.SQLException: Remote java.sql.SQLException: Fail to convert to internal representation
> at oracle.jdbc.driver.CharCommonAccessor.getBoolean(CharCommonAccessor.java:183)
> at oracle.jdbc.driver.GeneratedStatement.getBoolean(GeneratedStatement.java:129)
> at oracle.jdbc.driver.GeneratedScrollableResultSet.getBoolean(GeneratedScrollableResultSet.java:232)
> at org.jboss.jca.adapters.jdbc.WrappedResultSet.getBoolean(WrappedResultSet.java:594)
> at org.teiid.translator.jdbc.JDBCExecutionFactory.retrieveValue(JDBCExecutionFactory.java:1068)
> at org.teiid.translator.jdbc.JDBCQueryExecution.next(JDBCQueryExecution.java:344)
> ... 18 more
> {noformat}
> This is because it is pushed down as {{SDO_GEOM.RELATE}} with mask {{"disjoint"}}, which in oracle returns the string {{'DISJOINT'}} instead of the more expected {{'TRUE'}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4775) When using external materialization, after transaction timeout, LoadState continues to be LOADING
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4775?page=com.atlassian.jira.plugin... ]
Ramesh Reddy updated TEIID-4775:
--------------------------------
Component/s: Server
> When using external materialization, after transaction timeout, LoadState continues to be LOADING
> -------------------------------------------------------------------------------------------------
>
> Key: TEIID-4775
> URL: https://issues.jboss.org/browse/TEIID-4775
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7
> Environment: * CentOs 7
> * Teiid 9.1.2
> * Wildfly 10
> Reporter: Pedro Inácio
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
>
> For some unknown reason, sometimes a materialized view takes more time to finish the load/update than the one defined in transaction timeout (300 seconds is the default value, and we have configured 600 seconds to try to solve the problem).
> The transaction reaper will kill the update transaction. The _LoadState_ in _status_ table will be *LOADING*.
> Any subsequent try to update the view will fail, since the system reads the state as being *LOADING* even if the system is not currently updating it.
> Example log next.
> The update took too long (more than 10 minutes [defined transaction timeout]):
> {code:batch}
> 2017-02-17 16:10:44,487 INFO [org.teiid.COMMAND_LOG] (NIO6) gZueFR0aNjgi START USER COMMAND: startTime=2017-02-17 16:10:44.487 requestID=gZueFR0aNjgi.11 txID=null sessionID=gZueFR0aNjgi applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql={call SYSADMIN.loadMatView(?, ?)}
> 2017-02-17 16:20:44,528 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a080174:21ddbdf0:58a71a32:cb in state RUN
> 2017-02-17 16:20:44,564 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a080174:21ddbdf0:58a71a32:cb
> {code}
> Next I tried to update the view:
> {code:batch}
> 2017-02-17 16:29:21,272 INFO [org.teiid.COMMAND_LOG] (NIO2) E1xyKpChGKvC START USER COMMAND: startTime=2017-02-17 16:29:21.272 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql=EXECUTE SYSADMIN.loadMatView('CountryServiceListCalculatedRaw','country_service_list_calculated_raw')
> 2017-02-17 16:29:21,391 INFO [org.teiid.COMMAND_LOG] (Worker25_QueryProcessorQueue18136) E1xyKpChGKvC END USER COMMAND: endTime=2017-02-17 16:29:21.391 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 finalRowCount=1
> {code}
> And nothing happened.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4775) When using external materialization, after transaction timeout, LoadState continues to be LOADING
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4775?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-4775:
-----------------------------------
Fix Version/s: 9.3
Affects Version/s: 8.7
Assignee: Ramesh Reddy (was: Steven Hawkins)
> When using external materialization, after transaction timeout, LoadState continues to be LOADING
> -------------------------------------------------------------------------------------------------
>
> Key: TEIID-4775
> URL: https://issues.jboss.org/browse/TEIID-4775
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7
> Environment: * CentOs 7
> * Teiid 9.1.2
> * Wildfly 10
> Reporter: Pedro Inácio
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
>
> For some unknown reason, sometimes a materialized view takes more time to finish the load/update than the one defined in transaction timeout (300 seconds is the default value, and we have configured 600 seconds to try to solve the problem).
> The transaction reaper will kill the update transaction. The _LoadState_ in _status_ table will be *LOADING*.
> Any subsequent try to update the view will fail, since the system reads the state as being *LOADING* even if the system is not currently updating it.
> Example log next.
> The update took too long (more than 10 minutes [defined transaction timeout]):
> {code:batch}
> 2017-02-17 16:10:44,487 INFO [org.teiid.COMMAND_LOG] (NIO6) gZueFR0aNjgi START USER COMMAND: startTime=2017-02-17 16:10:44.487 requestID=gZueFR0aNjgi.11 txID=null sessionID=gZueFR0aNjgi applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql={call SYSADMIN.loadMatView(?, ?)}
> 2017-02-17 16:20:44,528 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a080174:21ddbdf0:58a71a32:cb in state RUN
> 2017-02-17 16:20:44,564 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a080174:21ddbdf0:58a71a32:cb
> {code}
> Next I tried to update the view:
> {code:batch}
> 2017-02-17 16:29:21,272 INFO [org.teiid.COMMAND_LOG] (NIO2) E1xyKpChGKvC START USER COMMAND: startTime=2017-02-17 16:29:21.272 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql=EXECUTE SYSADMIN.loadMatView('CountryServiceListCalculatedRaw','country_service_list_calculated_raw')
> 2017-02-17 16:29:21,391 INFO [org.teiid.COMMAND_LOG] (Worker25_QueryProcessorQueue18136) E1xyKpChGKvC END USER COMMAND: endTime=2017-02-17 16:29:21.391 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 finalRowCount=1
> {code}
> And nothing happened.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4775) When using external materialization, after transaction timeout, LoadState continues to be LOADING
by Pedro Inácio (JIRA)
Pedro Inácio created TEIID-4775:
-----------------------------------
Summary: When using external materialization, after transaction timeout, LoadState continues to be LOADING
Key: TEIID-4775
URL: https://issues.jboss.org/browse/TEIID-4775
Project: Teiid
Issue Type: Bug
Environment: * CentOs 7
* Teiid 9.1.2
* Wildfly 10
Reporter: Pedro Inácio
Assignee: Steven Hawkins
For some unknown reason, sometimes a materialized view takes more time to finish the load/update than the one defined in transaction timeout (300 seconds is the default value, and we have configured 600 seconds to try to solve the problem).
The transaction reaper will kill the update transaction. The _LoadState_ in _status_ table will be *LOADING*.
Any subsequent try to update the view will fail, since the system reads the state as being *LOADING* even if the system is not currently updating it.
Example log next.
The update took too long (more than 10 minutes [defined transaction timeout]):
{code:batch}
2017-02-17 16:10:44,487 INFO [org.teiid.COMMAND_LOG] (NIO6) gZueFR0aNjgi START USER COMMAND: startTime=2017-02-17 16:10:44.487 requestID=gZueFR0aNjgi.11 txID=null sessionID=gZueFR0aNjgi applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql={call SYSADMIN.loadMatView(?, ?)}
2017-02-17 16:20:44,528 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a080174:21ddbdf0:58a71a32:cb in state RUN
2017-02-17 16:20:44,564 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a080174:21ddbdf0:58a71a32:cb
{code}
Next I tried to update the view:
{code:batch}
2017-02-17 16:29:21,272 INFO [org.teiid.COMMAND_LOG] (NIO2) E1xyKpChGKvC START USER COMMAND: startTime=2017-02-17 16:29:21.272 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql=EXECUTE SYSADMIN.loadMatView('CountryServiceListCalculatedRaw','country_service_list_calculated_raw')
2017-02-17 16:29:21,391 INFO [org.teiid.COMMAND_LOG] (Worker25_QueryProcessorQueue18136) E1xyKpChGKvC END USER COMMAND: endTime=2017-02-17 16:29:21.391 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 finalRowCount=1
{code}
And nothing happened.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4734) Under some circumstances after restart Teiid Server does not update Materialized views anymore
by Pedro Inácio (JIRA)
[ https://issues.jboss.org/browse/TEIID-4734?page=com.atlassian.jira.plugin... ]
Pedro Inácio commented on TEIID-4734:
-------------------------------------
Opened as Bug in https://issues.jboss.org/browse/TEIID-4775
> Under some circumstances after restart Teiid Server does not update Materialized views anymore
> ----------------------------------------------------------------------------------------------
>
> Key: TEIID-4734
> URL: https://issues.jboss.org/browse/TEIID-4734
> Project: Teiid
> Issue Type: Bug
> Components: Common
> Affects Versions: 9.1.2
> Environment: * Wildfly 10
> * MySQL 5.6.32
> * Teiid Server 9.1.2
> Reporter: Pedro Inácio
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
> Attachments: StatusTableAfterStart.csv, StatusTableAfterStop.csv
>
>
> Under some circumstances, start and stop the server several times at different points, some Materialized Views are not being updated by the server.
> It is observable that in status table some views are no longer updated. In server log are being printed lots of INFO lines.
> Waited more than 15 minutes and the server was not capable of recovering.
> See the _StatusTableAfterStop.csv_ file to observe the status table content after stopping the server.
> See the _StatusTableAfterStart.csv_ file to observe the status table content after approximately 15 minutes after restart.
> Check _server.log_ for the Teiid Server log.
> See that hundreds of lines similar to the following occur
> {panel:title=Server.log}
> 2017-01-31 13:06:34,597 INFO [org.teiid.COMMAND_LOG] (Teiid Timer0) JfGY9cInAbrb START USER COMMAND: startTime=2017-01-31 13:06:34.597 requestID=JfGY9cInAbrb.0 txID=null sessionID=JfGY9cInAbrb applicationName=internal principal=embedded-async vdbName=CountryServiceListVDB vdbVersion=1 sql=execute SYSADMIN.matViewStatus('NumberingPlan', 'numbering_plan')
> {panel}
> The server cannot continue to load materialized views.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4734) Under some circumstances after restart Teiid Server does not update Materialized views anymore
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4734?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-4734 at 2/17/17 11:58 AM:
---------------------------------------------------------------
Transaction error is much more close to TEIID-4758, than this one. This is related entirely to restart of the server or its nodes.
Also, if load is taking more than 300 seconds, you would need to increase the timeout, but the issue is it not flipping the Status to FAILED_LOAD and leaving it in LOADING then that is an issue, for which you can open an issue.
was (Author: rareddy):
Transaction error is much more close to TEIID-4758, than this one. This is related entirely to restart of the server or its nodes.
> Under some circumstances after restart Teiid Server does not update Materialized views anymore
> ----------------------------------------------------------------------------------------------
>
> Key: TEIID-4734
> URL: https://issues.jboss.org/browse/TEIID-4734
> Project: Teiid
> Issue Type: Bug
> Components: Common
> Affects Versions: 9.1.2
> Environment: * Wildfly 10
> * MySQL 5.6.32
> * Teiid Server 9.1.2
> Reporter: Pedro Inácio
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
> Attachments: StatusTableAfterStart.csv, StatusTableAfterStop.csv
>
>
> Under some circumstances, start and stop the server several times at different points, some Materialized Views are not being updated by the server.
> It is observable that in status table some views are no longer updated. In server log are being printed lots of INFO lines.
> Waited more than 15 minutes and the server was not capable of recovering.
> See the _StatusTableAfterStop.csv_ file to observe the status table content after stopping the server.
> See the _StatusTableAfterStart.csv_ file to observe the status table content after approximately 15 minutes after restart.
> Check _server.log_ for the Teiid Server log.
> See that hundreds of lines similar to the following occur
> {panel:title=Server.log}
> 2017-01-31 13:06:34,597 INFO [org.teiid.COMMAND_LOG] (Teiid Timer0) JfGY9cInAbrb START USER COMMAND: startTime=2017-01-31 13:06:34.597 requestID=JfGY9cInAbrb.0 txID=null sessionID=JfGY9cInAbrb applicationName=internal principal=embedded-async vdbName=CountryServiceListVDB vdbVersion=1 sql=execute SYSADMIN.matViewStatus('NumberingPlan', 'numbering_plan')
> {panel}
> The server cannot continue to load materialized views.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4734) Under some circumstances after restart Teiid Server does not update Materialized views anymore
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4734?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4734:
-------------------------------------
Transaction error is much more close to TEIID-4758, than this one. This is related entirely to restart of the server or its nodes.
> Under some circumstances after restart Teiid Server does not update Materialized views anymore
> ----------------------------------------------------------------------------------------------
>
> Key: TEIID-4734
> URL: https://issues.jboss.org/browse/TEIID-4734
> Project: Teiid
> Issue Type: Bug
> Components: Common
> Affects Versions: 9.1.2
> Environment: * Wildfly 10
> * MySQL 5.6.32
> * Teiid Server 9.1.2
> Reporter: Pedro Inácio
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
> Attachments: StatusTableAfterStart.csv, StatusTableAfterStop.csv
>
>
> Under some circumstances, start and stop the server several times at different points, some Materialized Views are not being updated by the server.
> It is observable that in status table some views are no longer updated. In server log are being printed lots of INFO lines.
> Waited more than 15 minutes and the server was not capable of recovering.
> See the _StatusTableAfterStop.csv_ file to observe the status table content after stopping the server.
> See the _StatusTableAfterStart.csv_ file to observe the status table content after approximately 15 minutes after restart.
> Check _server.log_ for the Teiid Server log.
> See that hundreds of lines similar to the following occur
> {panel:title=Server.log}
> 2017-01-31 13:06:34,597 INFO [org.teiid.COMMAND_LOG] (Teiid Timer0) JfGY9cInAbrb START USER COMMAND: startTime=2017-01-31 13:06:34.597 requestID=JfGY9cInAbrb.0 txID=null sessionID=JfGY9cInAbrb applicationName=internal principal=embedded-async vdbName=CountryServiceListVDB vdbVersion=1 sql=execute SYSADMIN.matViewStatus('NumberingPlan', 'numbering_plan')
> {panel}
> The server cannot continue to load materialized views.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4734) Under some circumstances after restart Teiid Server does not update Materialized views anymore
by Pedro Inácio (JIRA)
[ https://issues.jboss.org/browse/TEIID-4734?page=com.atlassian.jira.plugin... ]
Pedro Inácio commented on TEIID-4734:
-------------------------------------
Hi,
I've observed that there is another situation where the views are no longer updated.
I don't know if you want me to open this in a different Ticket or not.
The situation is the following:
For some unknown reason, sometimes a materialized view takes more time to finish the load/update than the one defined in transaction timeout (300 seconds is the default value).
The transaction reaper will kill the update transaction. The _LoadState_ in _status_ table will be *LOADING*.
Any subsequent try to update the view will fail, since the system reads the state as being *LOADING* even if the system is not currently updating it.
Example log next.
The update took too long (more than 10 minutes [defined transaction timeout]):
{code:batch}
2017-02-17 16:10:44,487 INFO [org.teiid.COMMAND_LOG] (NIO6) gZueFR0aNjgi START USER COMMAND: startTime=2017-02-17 16:10:44.487 requestID=gZueFR0aNjgi.11 txID=null sessionID=gZueFR0aNjgi applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql={call SYSADMIN.loadMatView(?, ?)}
2017-02-17 16:20:44,528 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a080174:21ddbdf0:58a71a32:cb in state RUN
2017-02-17 16:20:44,564 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a080174:21ddbdf0:58a71a32:cb
{code}
Next I tried to update the view:
{code:batch}
2017-02-17 16:29:21,272 INFO [org.teiid.COMMAND_LOG] (NIO2) E1xyKpChGKvC START USER COMMAND: startTime=2017-02-17 16:29:21.272 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql=EXECUTE SYSADMIN.loadMatView('CountryServiceListCalculatedRaw','country_service_list_calculated_raw')
2017-02-17 16:29:21,391 INFO [org.teiid.COMMAND_LOG] (Worker25_QueryProcessorQueue18136) E1xyKpChGKvC END USER COMMAND: endTime=2017-02-17 16:29:21.391 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 finalRowCount=1
{code}
And nothing happened.
> Under some circumstances after restart Teiid Server does not update Materialized views anymore
> ----------------------------------------------------------------------------------------------
>
> Key: TEIID-4734
> URL: https://issues.jboss.org/browse/TEIID-4734
> Project: Teiid
> Issue Type: Bug
> Components: Common
> Affects Versions: 9.1.2
> Environment: * Wildfly 10
> * MySQL 5.6.32
> * Teiid Server 9.1.2
> Reporter: Pedro Inácio
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
> Attachments: StatusTableAfterStart.csv, StatusTableAfterStop.csv
>
>
> Under some circumstances, start and stop the server several times at different points, some Materialized Views are not being updated by the server.
> It is observable that in status table some views are no longer updated. In server log are being printed lots of INFO lines.
> Waited more than 15 minutes and the server was not capable of recovering.
> See the _StatusTableAfterStop.csv_ file to observe the status table content after stopping the server.
> See the _StatusTableAfterStart.csv_ file to observe the status table content after approximately 15 minutes after restart.
> Check _server.log_ for the Teiid Server log.
> See that hundreds of lines similar to the following occur
> {panel:title=Server.log}
> 2017-01-31 13:06:34,597 INFO [org.teiid.COMMAND_LOG] (Teiid Timer0) JfGY9cInAbrb START USER COMMAND: startTime=2017-01-31 13:06:34.597 requestID=JfGY9cInAbrb.0 txID=null sessionID=JfGY9cInAbrb applicationName=internal principal=embedded-async vdbName=CountryServiceListVDB vdbVersion=1 sql=execute SYSADMIN.matViewStatus('NumberingPlan', 'numbering_plan')
> {panel}
> The server cannot continue to load materialized views.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month