[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:
-------------------------------------
Given the number changes we are advocating in materialization as whole in 9.3 and number of users who are using the external managed materialization, I would rather we stick to above solution rather than another one which is involves best guesses.
> 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)
7 years, 10 months
[JBoss JIRA] (TEIID-4761) Support lpad/rpad pushdown to sql server
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4761:
-------------------------------------
Summary: Support lpad/rpad pushdown to sql server
Key: TEIID-4761
URL: https://issues.jboss.org/browse/TEIID-4761
Project: Teiid
Issue Type: Enhancement
Components: JDBC Connector
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.3
lpad/rpad is not pushded down to sql server since it lacked a direct equivalent - but it can be supported with an expression.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4734) Under some circumstances after restart Teiid Server does not update Materialized views anymore
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4734?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4734:
----------------------------------
Fix Version/s: 9.3
(was: 9.2)
We'll put this in 9.3 due to the status table change. The workaround for 9.2 and prior will be to manually issue the update to reset the loading state. Another approach would be to add a timeout based upon the number of spins through the mvstatus function.
> 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)
7 years, 10 months
[JBoss JIRA] (TEIID-4734) Under some circumstances after restart Teiid Server does not update Materialized views anymore
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4734?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4734:
---------------------------------------
This looks good. The only thought is if we want to future proof the change to the status table a little - do we want to add some additional columns even if unused to have only a single breaking change?
> 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.2
>
> 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)
7 years, 10 months
[JBoss JIRA] (TEIID-4760) optional object name manipulations while executing IMPORT FOREIGN SCHEMA
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4760?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIID-4760:
-------------------------------------
Component/s: Misc. Connectors
Fix Version/s: Open To Community
10.0
Assignee: (was: Steven Hawkins)
> optional object name manipulations while executing IMPORT FOREIGN SCHEMA
> ------------------------------------------------------------------------
>
> Key: TEIID-4760
> URL: https://issues.jboss.org/browse/TEIID-4760
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Reporter: Bram Gadeyne
> Labels: ddl, import, import_wizard
> Fix For: Open To Community, 10.0
>
>
> While executing IMPORT FOREIGN SCHEMA, table (and other object) names are added to the schema with their original names.
> In our previous virtual database we imported two schema's that contain the same objects but one is a production and another is a historical database.
> We then change the name for e.g. table1 to prod_table1 or wh_table1 according to the schema it came from. Some software that interacts with teiid can not distinguish between different schemas and can not handle duplicate table names. So for this reason, this would also come in handy.
> It would come in handy if it is possible to add a prefix to names while importing objects.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4758) Permanent materialization load failure is when target source goes down
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4758?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4758:
---------------------------------------
Exceptions are raised until caught.
> Permanent materialization load failure is when target source goes down
> ----------------------------------------------------------------------
>
> Key: TEIID-4758
> URL: https://issues.jboss.org/browse/TEIID-4758
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.12
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
>
> During the external materialization load, if the target cache database goes offline, the materialization job stops, but the {{Status}} table is left in {{LOADING}} state, which will never recover when the target cache database comes back up again.
> This situation is observed when JDG is used in OpenShift along with JDV However, behavior can occur in standalone situations too. The system should resilient and must recover in this situation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4760) optional object name manipulations while executing IMPORT FOREIGN SCHEMA
by Bram Gadeyne (JIRA)
Bram Gadeyne created TEIID-4760:
-----------------------------------
Summary: optional object name manipulations while executing IMPORT FOREIGN SCHEMA
Key: TEIID-4760
URL: https://issues.jboss.org/browse/TEIID-4760
Project: Teiid
Issue Type: Feature Request
Reporter: Bram Gadeyne
Assignee: Steven Hawkins
While executing IMPORT FOREIGN SCHEMA, table (and other object) names are added to the schema with their original names.
In our previous virtual database we imported two schema's that contain the same objects but one is a production and another is a historical database.
We then change the name for e.g. table1 to prod_table1 or wh_table1 according to the schema it came from. Some software that interacts with teiid can not distinguish between different schemas and can not handle duplicate table names. So for this reason, this would also come in handy.
It would come in handy if it is possible to add a prefix to names while importing objects.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4619) left join returns wrong results
by Bram Gadeyne (JIRA)
[ https://issues.jboss.org/browse/TEIID-4619?page=com.atlassian.jira.plugin... ]
Bram Gadeyne commented on TEIID-4619:
-------------------------------------
Hi Steven,
When I execute the query I can indeed see the expected rows being returned. The ordering does seem compatible with UCS-2/ASCII ordering.
> left join returns wrong results
> -------------------------------
>
> Key: TEIID-4619
> URL: https://issues.jboss.org/browse/TEIID-4619
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 9.0.4, 9.0.5
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.2.1
>
> Attachments: correct_result.txt, enclosed_queryplan.txt, query1_enclosed_plan.txt, query1_plan.txt, query2_plan.txt, teiid_reduced_case.txt, wrong_result.txt
>
>
> I have the following situation.
> I have a temporary table #tmp_admissions that contains 8047 rows.
> In this first query there are 66290 results. However if I only look at the lines for infectionid 880 then there are only 16 lines.
> {code:sql}
> select l.infectionid, l.id as linkid, lc.linkcultureid, lc.responsibleculture, lc.culturealternative, cl.sampleinsertts, cl.specimennumber,
> cl.culturenumber, cl.culturename, cl.quotation, ls.material, ls.sampletime,
> abr.culturenumber as abgram_culturenumber,abr.antibiogrampart, abr.resisttype,
> lc.antibiogramculturenr,lc.antibiogramspecimennr,lc.antibiogramsampleinsertts
> from #tmp_admissions adm
> join cos2_links l on l.admissionid = cast(adm.patientid as string)
> join cos2_link_culture lc on lc.linkid = l.id
> left join cos2_lab_culture cl on cl.culturenumber = lc.culturenr and cl.specimennumber = lc.culturespecimennr and cl.sampleinsertts = lc.culturesampleinsertts
> left join cos2_lab_sample ls on ls.inserttime = cl.sampleinsertts and ls.specimennumber = cl.specimennumber
> left join cos2_antibiogramresistences abr on abr.specimennumber = cl.specimennumber and abr.culturenumber = cl.culturenumber and abr.sampleinsertts = cl.sampleinsertts
> {code}
> This query does almost the same but returns 30 rows (and is correct).
> {code:sql}
> select l.infectionid, l.id as linkid, lc.linkcultureid, lc.responsibleculture, lc.culturealternative, cl.sampleinsertts, cl.specimennumber,
> cl.culturenumber, cl.culturename, cl.quotation, ls.material, ls.sampletime,
> abr.culturenumber as abgram_culturenumber,abr.antibiogrampart, abr.resisttype,
> lc.antibiogramculturenr,lc.antibiogramspecimennr,lc.antibiogramsampleinsertts
> from cos2_links l
> join cos2_link_culture lc on lc.linkid = l.id
> left join cos2_lab_culture cl on cl.culturenumber = lc.culturenr and cl.specimennumber = lc.culturespecimennr and cl.sampleinsertts = lc.culturesampleinsertts
> left join cos2_lab_sample ls on ls.inserttime = cl.sampleinsertts and ls.specimennumber = cl.specimennumber
> left join cos2_antibiogramresistences abr on abr.specimennumber = cl.specimennumber and abr.culturenumber = cl.culturenumber and abr.sampleinsertts = cl.sampleinsertts
> where l.infectionid = 880
> {code}
> cos2_link_culture contains 2 rows for this infectionid. The left join statements should result in 15 rows for both rows. However the left join results in the first query for the first row are null and to my understanding ignored. I'll attach the query plans for both queries.
> I should note that there is a one to many relation between infection and admission so therefore infectionid is for the same admission.
> Strangely enough if you enclode the first query in a group by query and count the rows it does indeed return 2 times 15 for the specific groups (see enclosed_queryplan.txt).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4759) PrestoDB - not all custom timezone IDs are supported
by Juraj Duráni (JIRA)
Juraj Duráni created TEIID-4759:
-----------------------------------
Summary: PrestoDB - not all custom timezone IDs are supported
Key: TEIID-4759
URL: https://issues.jboss.org/browse/TEIID-4759
Project: Teiid
Issue Type: Enhancement
Components: Documentation
Reporter: Juraj Duráni
Assignee: Juraj Duráni
Priority: Minor
The PrestoDB JDBC driver uses Joda Time library. If user needs to set custom timezone for Teiid server (e.g. exporting in JAVA_OPTS), he/she cannot use _GMT_ format as Joda Time does not recognize it \[1\]. However, equivalent format _Etc/*_ can be used (see [this page|http://joda-time.sourceforge.net/timezones.html]).
It would be nice to have a note in the documentation.
{code:plain|title=\[1\] Exception}
09:52:27,653 WARN [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue1) Connector worker process failed for atomic-request=5D1r1sDRkmmk.0.0.0: org.teiid.translator.jdbc.JDBCExecutionException: 0 TEIID11008:TEIID11004 Error executing statement(s): [SQL: SELECT g_0.intkey AS c_0, g_0.stringkey AS c_1, g_0.intnum AS c_2, g_0.stringnum AS c_3, g_0.floatnum AS c_4, g_0.longnum AS c_5, g_0.doublenum AS c_6, g_0.bytenum AS c_7, g_0.datevalue AS c_8, g_0.timevalue AS c_9, g_0.timestampvalue AS c_10, g_0.booleanvalue AS c_11, g_0.charvalue AS c_12, g_0.shortvalue AS c_13, cast(g_0.bigintegervalue AS bigint) AS c_14, g_0.bigdecimalvalue AS c_15, g_0.objectvalue AS c_16 FROM smalla AS g_0 LIMIT 100]
at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131) [translator-jdbc-8.12.5.redhat-8.jar:8.12.5.redhat-8]
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0-internal]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0-internal]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0-internal]
at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0-internal]
at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
at com.sun.proxy.$Proxy49.execute(Unknown Source)
at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
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) [rt.jar:1.8.0-internal]
at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
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) [rt.jar:1.8.0-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-internal]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal]
Caused by: java.sql.SQLException: Error executing query
at com.facebook.presto.jdbc.PrestoStatement.execute(PrestoStatement.java:232)
at com.facebook.presto.jdbc.PrestoStatement.executeQuery(PrestoStatement.java:69)
at org.jboss.jca.adapters.jdbc.WrappedStatement.executeQuery(WrappedStatement.java:344)
at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:119) [translator-jdbc-8.12.5.redhat-8.jar:8.12.5.redhat-8]
... 18 more
Caused by: java.lang.IllegalArgumentException: The datetime zone id 'GMT+01:00' is not recognised
at com.facebook.presto.jdbc.internal.joda.time.DateTimeZone.forID(DateTimeZone.java:229)
at com.facebook.presto.jdbc.PrestoResultSet.<init>(PrestoResultSet.java:122)
at com.facebook.presto.jdbc.PrestoStatement.execute(PrestoStatement.java:212)
... 21 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4758) Permanent materialization load failure is when target source goes down
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4758?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4758:
-------------------------------------
[~shawkins] Can you tell how the exception propagation is handled in Teiid procedure language? If a inner block throws an exception but does not catch it, but outer block has catch is it propagated to that? for ex:
{code}
CREATE VIRTUAL PROCEDURE ...
BEGIN
IF (FOO is 'BAR')
BEGIN
IF (X <> Y)
BEGIN
RAISE EXCEPTION ...;
END
EXCEPTION
logMsg("exception caught");
END
END
{code}
> Permanent materialization load failure is when target source goes down
> ----------------------------------------------------------------------
>
> Key: TEIID-4758
> URL: https://issues.jboss.org/browse/TEIID-4758
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.12
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
>
> During the external materialization load, if the target cache database goes offline, the materialization job stops, but the {{Status}} table is left in {{LOADING}} state, which will never recover when the target cache database comes back up again.
> This situation is observed when JDG is used in OpenShift along with JDV However, behavior can occur in standalone situations too. The system should resilient and must recover in this situation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months