[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 updated TEIID-4758:
--------------------------------
Parent: TEIID-4779
Issue Type: Sub-task (was: Bug)
> 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: Sub-task
> Components: Server
> Affects Versions: 8.12
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
>
> 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)
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:
--------------------------------
Parent: TEIID-4779
Issue Type: Sub-task (was: Bug)
> 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: Sub-task
> 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-4778) External Materialization, When TTL is less than loading time, the scheduling is off
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4778?page=com.atlassian.jira.plugin... ]
Ramesh Reddy updated TEIID-4778:
--------------------------------
Parent: TEIID-4779
Issue Type: Sub-task (was: Bug)
> External Materialization, When TTL is less than loading time, the scheduling is off
> -----------------------------------------------------------------------------------
>
> Key: TEIID-4778
> URL: https://issues.jboss.org/browse/TEIID-4778
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
>
> During managed external mateiralization,
> 1) if the TTL specified is less than the amount of load time
> 2) Then, if other nodes check the status at "LOADING", and the elapsed time is calculated from the time on the {{Status}} table. Which when goes over the TTL, it will be a negative value
> 3) Then, the scheduling algorithm schedules the next check immediately, which will be exactly same as one before as it also checks from the last updated time. Thus going into a tight loop which consume all the resources spinning.
> Correct this to check that, the scheduler always schedules next check atleast a default time after the previous one, which is currently at a minute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4778) External Materialization, When TTL is less than loading time, the scheduling is off
by Ramesh Reddy (JIRA)
Ramesh Reddy created TEIID-4778:
-----------------------------------
Summary: External Materialization, When TTL is less than loading time, the scheduling is off
Key: TEIID-4778
URL: https://issues.jboss.org/browse/TEIID-4778
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 8.7
Reporter: Ramesh Reddy
Assignee: Ramesh Reddy
Fix For: 9.3
During managed external mateiralization,
1) if the TTL specified is less than the amount of load time
2) Then, if other nodes check the status at "LOADING", and the elapsed time is calculated from the time on the {{Status}} table. Which when goes over the TTL, it will be a negative value
3) Then, the scheduling algorithm schedules the next check immediately, which will be exactly same as one before as it also checks from the last updated time. Thus going into a tight loop which consume all the resources spinning.
Correct this to check that, the scheduler always schedules next check atleast a default time after the previous one, which is currently at a minute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4777) google package name misspelled
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4777:
-------------------------------------
Summary: google package name misspelled
Key: TEIID-4777
URL: https://issues.jboss.org/browse/TEIID-4777
Project: Teiid
Issue Type: Quality Risk
Components: Misc. Connectors
Affects Versions: 8.13.3, 9.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.3
With TEIID-4070 the google package name was inadvertently changed to goole.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4668) Google translator skips NULL value in INSERT
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4668?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4668:
---------------------------------
Fix Version/s: 8.12.10.6_3
> Google translator skips NULL value in INSERT
> --------------------------------------------
>
> Key: TEIID-4668
> URL: https://issues.jboss.org/browse/TEIID-4668
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.8.6_3
> Reporter: Lucie Fabrikova
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 9.0.6, 9.1.2, 9.2, 8.12.10.6_3
>
> Attachments: google-crud.png, googlespreadsheetcrud-vdb.xml
>
>
> I have google spreadsheet table smalla with defined header columns intkey, intnum and other (see attached screenshot).
> Following query doesn't insert NULL value to column intnum:
> INSERT INTO smalla(intnum, intkey) values (null, 562)
> Instead, it inserts 562 to intnum and NULL to intkey.
> (Server log shows no exception)
> INSERT works correctly if none of the inserted values is NULL.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4667) Oracle translator - parseTime throws exception if string has extra trailing characters after standard time format
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4667?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4667:
---------------------------------
Fix Version/s: 8.12.10.6_3
> Oracle translator - parseTime throws exception if string has extra trailing characters after standard time format
> -----------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4667
> URL: https://issues.jboss.org/browse/TEIID-4667
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.10.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 9.2, 8.12.10.6_3
>
>
> TEIID-4656 was meant to prevent ORA-01830 (date format picture ends before converting entire input string). However, this has not been fully fixed for parseTime function. TO_TIMESTAMP is not pushed, but Teiid uses TO_CHAR which has similar behavior for strings with extra trailing characters.
> From my test:
> {code:sql|title=Oracle data source}
> CREATE TABLE teiid4656 (id number(1) PRIMARY KEY, col varchar(23))
> INSERT INTO teiid4656 (id, col) VALUES (1, '2016-24-12 20:00:00.111')
> INSERT INTO teiid4656 (id, col) VALUES (2, '20:00:00.111 2016-24-12')
> {code}
> *Query 1:*
> {code:sql}
> SELECT CAST(PARSEDATE(col, 'yyyy-dd-MM') AS string) FROM teiid4656 WHERE id = 1
> {code}
> *Result 1 (OK):* 2016-12-24
> *Query 2:*
> {code:sql}
> SELECT CAST(PARSETIME(col, 'hh:mm:ss') AS string) FROM teiid4656 WHERE id = 2
> {code}
> *Result 2 (Exception):*
> {code:plain|title=Server log}
> 07:27:48,165 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue4) NHKd8fOn5GvJ.0 executing SELECT CAST(PARSETIME(col, 'hh:mm:ss') AS string) FROM teiid4656 WHERE id = 2
> 07:27:48,169 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue4) ProcessTree for NHKd8fOn5GvJ.0 AccessNode(0) output=[convert(convert(Source.teiid4656.col, TIME), string)] SELECT convert(convert(g_0.col, TIME), string) FROM Source.teiid4656 AS g_0 WHERE g_0.id = 2
> 07:27:48,169 DEBUG [org.teiid.TXN_LOG] (Worker0_QueryProcessorQueue4) before getOrCreateTransactionContext:org.teiid.dqp.internal.process.TransactionServerImpl@cd77a59(NHKd8fOn5GvJ)
> 07:27:48,169 DEBUG [org.teiid.TXN_LOG] (Worker0_QueryProcessorQueue4) after getOrCreateTransactionContext : NHKd8fOn5GvJ NONE ID:NONE
> 07:27:48,170 DEBUG [org.teiid.BUFFER_MGR] (Worker0_QueryProcessorQueue4) Creating TupleBuffer: 1 [convert(convert(Source.teiid4656.col, TIME), string)] [class java.lang.String] batch size 1024 of type PROCESSOR
> 07:27:48,170 DEBUG [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue4) NHKd8fOn5GvJ.0.0.1 Create State
> 07:27:48,171 DEBUG [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue5) Running task for parent thread Worker0_QueryProcessorQueue4
> 07:27:48,171 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue5) NHKd8fOn5GvJ.0.0.1 Processing NEW request: SELECT convert(convert(g_0.col, TIME), string) FROM Source.teiid4656 AS g_0 WHERE g_0.id = 2
> 07:27:48,172 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue5) NHKd8fOn5GvJ.0.0.1 Obtained execution
> 07:27:48,173 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue5) Source-specific command: SELECT to_char(to_date(g_0.col, 'HH24:MI:SS'), 'HH24:MI:SS') FROM teiid4656 g_0 WHERE g_0.id = 2
> 07:27:48,174 DEBUG [org.teiid.BUFFER_MGR] (Worker0_QueryProcessorQueue4) NHKd8fOn5GvJ.0.0.1 Blocking on source query NHKd8fOn5GvJ.0.0.1
> 07:27:48,174 DEBUG [org.teiid.BUFFER_MGR] (Worker0_QueryProcessorQueue4) NHKd8fOn5GvJ.0 Blocking on source request(s).
> 07:27:48,174 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue4) Request Thread NHKd8fOn5GvJ.0 - processor blocked
> 07:27:48,486 WARN [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue5) Connector worker process failed for atomic-request=NHKd8fOn5GvJ.0.0.1: org.teiid.translator.jdbc.JDBCExecutionException: 1830 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT to_char(to_date(g_0.col, 'HH24:MI:SS'), 'HH24:MI:SS') FROM teiid4656 g_0 WHERE g_0.id = 2]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:337) [teiid-engine-8.7.11.6_2-redhat-1.jar:8.7.11.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:298) [teiid-engine-8.7.11.6_2-redhat-1.jar:8.7.11.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:110) [teiid-engine-8.7.11.6_2-redhat-1.jar:8.7.11.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:107) [teiid-engine-8.7.11.6_2-redhat-1.jar:8.7.11.6_2-redhat-1]
> 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:58) [teiid-engine-8.7.11.6_2-redhat-1.jar:8.7.11.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.11.6_2-redhat-1.jar:8.7.11.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.11.6_2-redhat-1.jar:8.7.11.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.11.6_2-redhat-1.jar:8.7.11.6_2-redhat-1]
> 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.SQLDataException: ORA-01830: date format picture ends before converting entire input string
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)
> at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1017)
> at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:655)
> at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:249)
> at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:566)
> at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:215)
> at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:58)
> at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:776)
> at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:897)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1034)
> at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3820)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3867)
> at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1502)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:123)
> ... 12 more
> {code}
> *Query 3:*
> {code:sql}
> SELECT CAST(PARSETIMESTAMP(col, 'yyyy-dd-MM hh:mm') AS string) FROM teiid4656 WHERE id = 1
> {code}
> *Result 3 (OK):* 2016-12-24 20:00:00.0
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4744) Prior execution is not being closed in transactional secenario
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4744?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4744:
---------------------------------
Fix Version/s: 8.12.10.6_3
> Prior execution is not being closed in transactional secenario
> --------------------------------------------------------------
>
> Key: TEIID-4744
> URL: https://issues.jboss.org/browse/TEIID-4744
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Fix For: 9.2, 8.7.12.6_2, 8.12.10.6_3
>
>
> When working in transactional scenario, where all the queries in plan are executed serially in a given thread, however, JDBC drivers like Netezza do not allow to keep more than single statement open on a given connection.
> To work with this issue, Teiid provides a translator override called "ThreadBound" where it forces the previous statement to finish executing (it caches the results if needs to be) before it can execute the next source command on the same connection. It looks like Teiid is not closing the prior statement before it moves on to execute the next statement.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (TEIID-4737) Incorrect work of left join statement
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4737?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4737:
---------------------------------
Fix Version/s: 8.12.10.6_3
> Incorrect work of left join statement
> -------------------------------------
>
> Key: TEIID-4737
> URL: https://issues.jboss.org/browse/TEIID-4737
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0.3
> Environment: teiid-9.0.3 on WildFly Full 9.0.2.Final (WildFly Core 1.0.2.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 9.0.6, 9.2, 9.1.4, 8.7.12.6_2, 8.12.10.6_3
>
> Attachments: test_emails_bug1.jpg, test_emails_pg.jpg
>
>
> the following query:
> {code:sql}
> SELECT a.email, b.email, lower(a.email), lower(b.email) FROM test_tables.test_emails as a left join views.test_view_emails as b on lower(a.email)=lower(b.email)
> {code}
> leads to the following results:
> !test_emails_bug1.jpg|thumbnail!
> though running the same query on PostgreSQL leads to the following results:
> !test_emails_pg.jpg|thumbnail!
> so this query mentioned above must work as on PostgreSQL putting null values for the b field table where conditions can't be performed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month