April 2011 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-1559) Dynamic VDB deployed in inactive state on Oracle11g

by Boris Belovic (JIRA)

Dynamic VDB deployed in inactive state on Oracle11g --------------------------------------------------- Key: TEIID-1559 URL: https://issues.jboss.org/browse/TEIID-1559 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 7.1.1 Environment: Oracle 11g R2, driver version: 11.2.0.1.0 Teiid 7.1.1 in SOA-P 5.1 Reporter: Boris Belovic Assignee: Steven Hawkins Dynamic VDB is deployed in inactive state on SOA-P 5.1 server configured with Oracle 11g R2 database. First I deploy both datasources required by VDB and then dynamic VDB itself. But the VDB remains in inactive state, despite all datasources referred by this VDB are in place (= deployed correctly). Few seconds after deployment of VDB I got this exception from the server. 08:42:24,335 INFO [RUNTIME] VDB "myvdb-1" - "Employees" model metadata is currently being loaded. Start Time: 4/19/11 8:42 AM 08:42:24,355 INFO [PROCESSOR] Clearing prepared plan cache 08:42:24,358 INFO [RUNTIME] VDB "myvdb.1[Employees[oracle-connector/oracle/java:DefaultDS], TextFileData[text-connector/file/java:TxtFileDS]]" deployed in inactive state. 08:42:50,307 WARN [RunnableTaskWrapper] Unhandled throwable for runnable: org.teiid.deployers.VDBDeployer$1@13bf30c java.lang.AssertionError: Duplicate Table APEX_ACTIVITY_LOG at org.teiid.metadata.Schema.addTable(Schema.java:42) at org.teiid.metadata.MetadataFactory.addTable(MetadataFactory.java:82) at org.teiid.translator.jdbc.JDBCMetdataProcessor.getTables(JDBCMetdataProcessor.java:195) at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:110) at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:268) at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:80) at org.teiid.dqp.internal.datamgr.ConnectorManager.getMetadata(ConnectorManager.java:125) at org.teiid.deployers.VDBDeployer.loadMetadata(VDBDeployer.java:310) at org.teiid.deployers.VDBDeployer.access$000(VDBDeployer.java:59) at org.teiid.deployers.VDBDeployer$1.run(VDBDeployer.java:293) at org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:147) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) I also tried deploying this VDB on MySQL 5.1 and PostgreSQL 8.3 and the VDB was deployed without any problems or exceptions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
17
0 / 0

[JBoss JIRA] Created: (TEIID-1566) More complex join: ORDER BY and LIMIT not pushed down

by Mark Addleman (JIRA)

More complex join: ORDER BY and LIMIT not pushed down ------------------------------------------------------ Key: TEIID-1566 URL: https://issues.jboss.org/browse/TEIID-1566 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Mark Addleman Assignee: Steven Hawkins Query: SELECT B."SYSID", B."USERID", J0.APPNAME as "SYSOFUSER@APPNAME", B."NAME", B."PROC", B."SUSPEND", B."UID", (select count(*) from (select * from notes.RETRIEVE_NOTES where OBJECT_PKEY = xmlserialize(xmlelement("SECURITY.BASEUSER", XMLATTRIBUTES(B."SYSID",B."USERID")) as String)) as foo) as C_notesForObject, 'SECURITY.BASEUSER' as "__objecttype__" FROM "SECURITY.BASEUSER" as B left join security.sysinfo J0 on J0.sysid=B.sysid ORDER BY J0.APPNAME ASC LIMIT 9990,10; args: [] I think there are two problems with the plan for this query: First, neither the ORDER BY nor the LIMIT clause are pushed down to DB2. However, if it is was pushed down, the plan should apply the ORDER & LIMIT before it tries to join to the notes table. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
9
0 / 0

[JBoss JIRA] Created: (TEIID-1529) LIMIT not pushed down for queries with subselects and ORDER BY

by Mark Addleman (JIRA)

LIMIT not pushed down for queries with subselects and ORDER BY -------------------------------------------------------------- Key: TEIID-1529 URL: https://issues.jboss.org/browse/TEIID-1529 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.3 Reporter: Mark Addleman Assignee: Steven Hawkins It doesn't look like the engine pushes down LIMIT in the following query: SELECT B."SYSID", B."USERID", (SELECT COUNT(*) FROM (SELECT * FROM notes.RETRIEVE_NOTES WHERE OBJECT_PKEY = XMLSERIALIZE(XMLELEMENT("SECURITY.BASEUSER", XMLATTRIBUTES(B."SYSID",B."USERID")) as String)) as foo) as C_notesForObject, 'SECURITY.BASEUSER' as "__objecttype__" FROM "SECURITY.BASEUSER" as B ORDER BY B."USERID" ASC LIMIT 10 However, the engine does push down the LIMIT in the same query without the ORDER BY: SELECT B."SYSID", B."USERID", (SELECT COUNT(*) FROM (SELECT * FROM notes.RETRIEVE_NOTES WHERE OBJECT_PKEY = XMLSERIALIZE(XMLELEMENT("SECURITY.BASEUSER", XMLATTRIBUTES(B."SYSID",B."USERID")) as String)) as foo) as C_notesForObject, 'SECURITY.BASEUSER' as "__objecttype__" FROM "SECURITY.BASEUSER" as B LIMIT 10 Another piece of relevant information is notes.RETRIEVE_NOTE is a stored procedure backed by java code in a translator. Since SECURITY.BASEER contains ~20,000 rows and each row requires a select against the RETRIEVE_NOTE stored procedure, the difference in processing time is huge: about two minutes with the ORDER BY versus a few hundred milliseconds without the ORDER BY. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
8
0 / 0

[JBoss JIRA] Created: (TEIID-1547) Need Java 1.5-compliant JDBC driver for Data Services

by Len DiMaggio (JIRA)

Need Java 1.5-compliant JDBC driver for Data Services ----------------------------------------------------- Key: TEIID-1547 URL: https://issues.jboss.org/browse/TEIID-1547 Project: Teiid Issue Type: Feature Request Components: JDBC Driver Affects Versions: 7.4 Reporter: Len DiMaggio Assignee: Steven Hawkins Project JIRA for: SOA-2999 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-1562) ArrayIndexOutOfBounds and ASSERTION FAILED in models with UNION

by Claudio Venturini (JIRA)

ArrayIndexOutOfBounds and ASSERTION FAILED in models with UNION --------------------------------------------------------------- Key: TEIID-1562 URL: https://issues.jboss.org/browse/TEIID-1562 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.3, 7.4 Environment: Teiid 7.3/7.4 beta2 deployed on JBoss AS 5.1, installed on Ubuntu Server 10.04 LTS. Three source models, two of which in MySQL 5.1.51 (on the same machine of JBoss), and one on SQLServer 2000 (on another machine). Reporter: Claudio Venturini Assignee: Steven Hawkins I've three simple source models. Two of them (namely "support_phy" and "oasi_phy") are on MySQL, and one ("tricolore_phy") on SQL Server 2000. I also have three view models, one for each source model, named "support_log", "oasi_log" and "tricolore_log". Don't mind the names... Every model has only one table. Each of these view models reflects one of the source models. In addition I have a fourth view model, named "aop", which integrates the data from the other view models using a simple UNION ALL operation. In particular this view model is defined by the following query: {code:sql} SELECT TR_v.data AS data_fattura, TR_v.n_prog, TR_v.quantita FROM tricolore_log.misura124.tricolore.vendita_referenza AS TR_v UNION ALL SELECT OA_v.data AS data_fattura, OA_v.n_prog, OA_v.quantita FROM oasi_log.misura124.oasi.vendita_referenza AS OA_v {code} One problem is that if I execute the following query, against the integrated model: {code:sql} SELECT data_fattura, n_prog, quantita FROM aop.misura124.aop.vendita_referenza WHERE n_prog = 1 {code} I get a ArrayIndexOutOfBoundsException: {code} 2011-04-20 17:26:26,332 DEBUG [org.teiid.COMMAND_LOG] (New I/O server worker #1-1) START USER COMMAND: startTime=2011-04-20 17:26:26.332 requestID=8LzPNHldNJhu.2 txID=null sessionID=8LzPNHldNJhu applicationName=JDBC principal=admin@teiid-security vdbName=misura124 vdbVersion=1sql=SELECT data_fattura, n_prog, quantita FROM aop.misura124.aop.vendita_referenza where n_prog = 1 2011-04-20 17:26:26,373 DEBUG [org.teiid.COMMAND_LOG] (Worker163_QueryProcessorQueue7610) ERROR USER COMMAND: endTime=2011-04-20 17:26:26.373 requestID=8LzPNHldNJhu.2 txID=null sessionID=8LzPNHldNJhu principal=admin@teiid-security vdbName=misura124 vdbVersion=1 finalRowCount=null 2011-04-20 17:26:26,373 ERROR [org.teiid.PROCESSOR] (Worker163_QueryProcessorQueue7610) Unexpected exception for request 8LzPNHldNJhu.2 java.lang.ArrayIndexOutOfBoundsException {code} I've tried to swap the order of the SELECTs statements in the query as follows: {code:sql} SELECT OA_v.data AS data_fattura, OA_v.n_prog, OA_v.quantita FROM oasi_log.misura124.oasi.vendita_referenza AS OA_v UNION ALL SELECT TR_v.data AS data_fattura, TR_v.n_prog, TR_v.quantita FROM tricolore_log.misura124.tricolore.vendita_referenza AS TR_v {code} Surprisingly it works!! This was the first problem. While finding a solution to that problem, I found a second problem. The definition of the table in the "tricolore_log" model is as follows: {code:sql} SELECT TR_v.DataDocumento AS data, 1 AS n_prog, CAST(SUM(TR_v.NrPezzi) AS INTEGER) AS quantita FROM tricolore_phy.Tricolore.dbo.DISCO_Vendita_Referenza AS TR_v INNER JOIN support_log.mediator.referenza_op AS SUP_r ON TR_v.Cod_Dsc = SUP_r.codice WHERE SUP_r.codop = 1 GROUP BY TR_v.DataDocumento, COALESCE(NULLIF(RTRIM(LTRIM(TR_v.NumeroDocumento)), ''), 'N.D.') {code} The GROUP BY clause is a little bit complex, so I tried to simplify it by removing the COALESCE function, thereby maintaining in the clause only the TR_v.DataDocumento field. I've run the same query on the integrated schema, and the result is an ASSERTION FAILED error: {code} 2011-04-20 17:06:33,572 DEBUG [org.teiid.COMMAND_LOG] (New I/O server worker #1-2) START USER COMMAND: startTime=2011-04-20 17:06:33.571 requestID=iMaBNssX10Nx.0 txID=null sessionID=iMaBNssX10Nx applicationName=JDBC principal=admin@teiid-security vdbName=misura124 vdbVersion=1sql=SELECT data_fattura, n_prog, quantita FROM aop.misura124.aop.vendita_referenza where n_prog = 1 2011-04-20 17:06:33,586 DEBUG [org.teiid.COMMAND_LOG] (Worker158_QueryProcessorQueue7536) ERROR USER COMMAND: endTime=2011-04-20 17:06:33.586 requestID=iMaBNssX10Nx.0 txID=null sessionID=iMaBNssX10Nx principal=admin@teiid-security vdbName=misura124 vdbVersion=1 finalRowCount=null 2011-04-20 17:06:33,588 ERROR [org.teiid.PROCESSOR] (Worker158_QueryProcessorQueue7536) Unexpected exception for request iMaBNssX10Nx.0 java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null at org.teiid.core.util.Assertion.failed(Assertion.java:73) at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100) at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92) at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367) at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:129) at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:103) at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:108) at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:108) at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:108) at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:108) at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:98) at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:175) at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:125) at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:104) at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:305) at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:233) at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:56) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:197) at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:118) at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) {code} Worst of all, the clients seems to not recognize the error, and thus it continues to wait for a response which will never arrive. From the client point of view, the server seems to be in a infinite loop. In addition the query works either by completely removing the GROUP BY clause, or removing the INNER JOIN and the WHERE clauses. But these can not be considered as workarounds because they change the semantics of the model. I found the two bugs using Teiid 7.3 patched with https://issues.jboss.org/browse/TEIID-1458 and https://issues.jboss.org/browse/TEIID-1465, and then I upgraded to Teiid 7.4 beta2, which doesn't solve the problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (TEIID-1553) UDF Function model fails to load when it located inside a folder in the VDB

by Ramesh Reddy (JIRA)

UDF Function model fails to load when it located inside a folder in the VDB --------------------------------------------------------------------------- Key: TEIID-1553 URL: https://issues.jboss.org/browse/TEIID-1553 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 7.1.1 Reporter: Ramesh Reddy When UDF is modelled under folder the VDB deployer fails to load the function model. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (TEIID-1564) Clustered Caching Not Working

by Ramesh Reddy (JIRA)

Clustered Caching Not Working ----------------------------- Key: TEIID-1564 URL: https://issues.jboss.org/browse/TEIID-1564 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 7.2, 7.1.1 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 7.4 I have configured two Teiid servers in a cluster and renamed the teiid-cache-manager-jboss-beans-rename-me.xml file to enable clustered caching. I submit a query to one node and see in the log that the internal materialized view is being cached on that node. When I submit the same query to the second node, i see the following error: 12:17:12,040 INFO [MATVIEWS] Loading materialized view table #MAT_CACHED.TEIID.EDS_TAB1_MV 12:17:12,041 WARN [PROCESSOR] Processing exception 'Temporary table "#MAT_CACHED.TEIID.EDS_TAB1_MV" does not exist.' for request BBcYbxuqEAHL.5. Exception type org.teiid.api.exception.query.QueryProcessingException thrown from org.teiid.query.tempdata.TempTableStore.getOrCreateTempTable(TempTableStore.java:220). Enable more detailed logging to see the entire stacktrace. 12:17:12,165 ERROR [MATVIEWS] Failed to load materialized view table #MAT_CACHED.TEIID.EDS_TAB1_MV. [BlockedException] at org.teiid.common.buffer.BlockedException.<clinit>(BlockedException.java:34) at org.teiid.common.buffer.TupleBuffer$1.finalRow(TupleBuffer.java:290) at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:69) at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48) at org.teiid.query.tempdata.TempTable$UpdateProcessor.process(TempTable.java:205) at org.teiid.query.tempdata.TempTable.insert(TempTable.java:446) at org.teiid.query.tempdata.TempTableDataManager.loadGlobalTable(TempTableDataManager.java:516) at org.teiid.query.tempdata.TempTableDataManager.access$100(TempTableDataManager.java:105) at org.teiid.query.tempdata.TempTableDataManager$2.call(TempTableDataManager.java:443) at org.teiid.query.tempdata.TempTableDataManager$2.call(TempTableDataManager.java:440) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188) at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116) at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Case:00451425 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-1531) ODBC charset issues

by Steven Hawkins (JIRA)

ODBC charset issues ------------------- Key: TEIID-1531 URL: https://issues.jboss.org/browse/TEIID-1531 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 7.1.1 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.4 In testing odbc using the postgres jdbc issue I can see that we are not consistently handling the conversion of client encodings to charsets. Also later postgres clients can use the key UNICODE to refer to UTF-8. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (TEIID-1164) Getting the Procedure Parameter metadata is not supported in ODBC

by Ramesh Reddy (JIRA)

Getting the Procedure Parameter metadata is not supported in ODBC ----------------------------------------------------------------- Key: TEIID-1164 URL: https://jira.jboss.org/browse/TEIID-1164 Project: Teiid Issue Type: Bug Components: ODBC Affects Versions: 7.1 Reporter: Ramesh Reddy Currently postgreSQL uses the JDBC array types in issuing the query to read the Procedure parameters. However, Teiid does not support the Array types yet in the JDBC layer, thus this is currently not implemented. This needs to be fixed to correctly return the metadata about the procedures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
7
0 / 0

[JBoss JIRA] Created: (TEIID-1570) pg catalog transformation issues

by Steven Hawkins (JIRA)

pg catalog transformation issues -------------------------------- Key: TEIID-1570 URL: https://issues.jboss.org/browse/TEIID-1570 Project: Teiid Issue Type: Bug Components: ODBC Affects Versions: 7.1.1 Reporter: Steven Hawkins Assignee: Steven Hawkins pg_class and pg_index view definitions have type mismatches. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2011