December 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger) metadata document based on OData

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5555: ---------------------------------- Fix Version/s: 11.2.2 (was: 11.2.1) > Create OpenAPI (swagger) metadata document based on OData > --------------------------------------------------------- > > Key: TEIID-5555 > URL: https://issues.jboss.org/browse/TEIID-5555 > Project: Teiid > Issue Type: Enhancement > Components: OData > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Blocker > Fix For: 12.0, 11.2.2 > > > Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5564) Batch removed during large temp table load

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5564?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5564: ---------------------------------- Description: For a sufficiently large temp operation, such as a merge over 2.5 million rows, you can see: java.lang.AssertionError: Batch not found in storage 58804 at org.teiid.common.buffer.impl.BufferManagerImpl$BatchManagerImpl.getBatch(BufferManagerImpl.java:382) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] at org.teiid.common.buffer.SPage.getValues(SPage.java:240) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] at org.teiid.common.buffer.SPage.search(SPage.java:139) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] at org.teiid.common.buffer.STree.find(STree.java:249) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] at org.teiid.common.buffer.STree.remove(STree.java:429) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] at org.teiid.query.tempdata.TempTable.deleteTuple(TempTable.java:802) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] at org.teiid.query.tempdata.TempTable.access$500(TempTable.java:83) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] at org.teiid.query.tempdata.TempTable$InsertUpdateProcessor.undo(TempTable.java:159) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] Which occurs during undo/rollback of an operation and masks the underlying exception. The actual error will typically be the same as TEIID-5439, the proactive removal of the managed batches once a space limit has been reached. This did not occur after the TEIID-5439 fix upstream, but it appears it could have still occurred - and did occur on 8.12.x. was: For a sufficiently large materialization, such as 33000000 rows by 10 columns of biginteger/string types, the load will not complete and instead produce an exception: {code} ERROR: TEIID30019 Unexpected exception for request yGKKEfVoiD5O.0 org.teiid.core.TeiidRuntimeException: Batch removed at org.teiid.query.tempdata.TempTableDataManager.rethrow(TempTableDataManager.java:880) at org.teiid.query.tempdata.TempTableDataManager.access$800(TempTableDataManager.java:92) at org.teiid.query.tempdata.TempTableDataManager$4.load(TempTableDataManager.java:625) at org.teiid.query.tempdata.TempTableDataManager$4.createTupleSource(TempTableDataManager.java:548) at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:108) at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:401) at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:141) at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:148) at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:111) at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160) at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:142) at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:492) {code} > Batch removed during large temp table load > ------------------------------------------ > > Key: TEIID-5564 > URL: https://issues.jboss.org/browse/TEIID-5564 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0, 11.2.2 > > > For a sufficiently large temp operation, such as a merge over 2.5 million rows, you can see: > java.lang.AssertionError: Batch not found in storage 58804 > at org.teiid.common.buffer.impl.BufferManagerImpl$BatchManagerImpl.getBatch(BufferManagerImpl.java:382) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] > at org.teiid.common.buffer.SPage.getValues(SPage.java:240) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] > at org.teiid.common.buffer.SPage.search(SPage.java:139) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] > at org.teiid.common.buffer.STree.find(STree.java:249) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] > at org.teiid.common.buffer.STree.remove(STree.java:429) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] > at org.teiid.query.tempdata.TempTable.deleteTuple(TempTable.java:802) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] > at org.teiid.query.tempdata.TempTable.access$500(TempTable.java:83) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] > at org.teiid.query.tempdata.TempTable$InsertUpdateProcessor.undo(TempTable.java:159) [teiid-engine-8.12.16.6_4-redhat-64-2.jar:8.12.16.6_4-redhat-64-2] > Which occurs during undo/rollback of an operation and masks the underlying exception. The actual error will typically be the same as TEIID-5439, the proactive removal of the managed batches once a space limit has been reached. > This did not occur after the TEIID-5439 fix upstream, but it appears it could have still occurred - and did occur on 8.12.x. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5564) Batch removed during large temp table load

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5564?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5564: ---------------------------------- Fix Version/s: 11.2.2 12.0 (was: 11.1) (was: 10.3.4) (was: 11.0.2) (was: 8.12.16.6_4) > Batch removed during large temp table load > ------------------------------------------ > > Key: TEIID-5564 > URL: https://issues.jboss.org/browse/TEIID-5564 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0, 11.2.2 > > > For a sufficiently large materialization, such as 33000000 rows by 10 columns of biginteger/string types, the load will not complete and instead produce an exception: > {code} > ERROR: TEIID30019 Unexpected exception for request yGKKEfVoiD5O.0 > org.teiid.core.TeiidRuntimeException: Batch removed > at org.teiid.query.tempdata.TempTableDataManager.rethrow(TempTableDataManager.java:880) > at org.teiid.query.tempdata.TempTableDataManager.access$800(TempTableDataManager.java:92) > at org.teiid.query.tempdata.TempTableDataManager$4.load(TempTableDataManager.java:625) > at org.teiid.query.tempdata.TempTableDataManager$4.createTupleSource(TempTableDataManager.java:548) > at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:108) > at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:401) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) > at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:141) > at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:148) > at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:111) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:142) > at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:492) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5564) Batch removed during large temp table load

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5564: ------------------------------------- Summary: Batch removed during large temp table load Key: TEIID-5564 URL: https://issues.jboss.org/browse/TEIID-5564 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 11.1, 10.3.4, 11.0.2, 8.12.16.6_4 For a sufficiently large materialization, such as 33000000 rows by 10 columns of biginteger/string types, the load will not complete and instead produce an exception: {code} ERROR: TEIID30019 Unexpected exception for request yGKKEfVoiD5O.0 org.teiid.core.TeiidRuntimeException: Batch removed at org.teiid.query.tempdata.TempTableDataManager.rethrow(TempTableDataManager.java:880) at org.teiid.query.tempdata.TempTableDataManager.access$800(TempTableDataManager.java:92) at org.teiid.query.tempdata.TempTableDataManager$4.load(TempTableDataManager.java:625) at org.teiid.query.tempdata.TempTableDataManager$4.createTupleSource(TempTableDataManager.java:548) at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:108) at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:401) at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:277) at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:141) at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:148) at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:111) at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:160) at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:142) at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:492) {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5356) Infer field metadata from the source columns

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/TEIID-5356?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-5356: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1656428 Bugzilla Update: Perform > Infer field metadata from the source columns > -------------------------------------------- > > Key: TEIID-5356 > URL: https://issues.jboss.org/browse/TEIID-5356 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Chandra Akkinepalli > Assignee: Steven Hawkins > Priority: Major > Fix For: 11.0 > > > This is an observation made in dynamic vdbs. > When a view is defined without column name , data type, length as in the example below > create view xyz as ( > select a, b, c from view_model.example > ); > instead of inferring the column metadata from view_model, the string columns are created with length =4000, this is causing issues when querying such views from visualization tools like Tableau, these fields are forced to be converted to text and failing in the process. > I would like to request an enhancement for dynamic vdbs to infer metadata from sources in such cases. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5369) enableDependentJoins for Redshift translator

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/TEIID-5369?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-5369: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1656419 Bugzilla Update: Perform > enableDependentJoins for Redshift translator > -------------------------------------------- > > Key: TEIID-5369 > URL: https://issues.jboss.org/browse/TEIID-5369 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector > Reporter: Chandra Akkinepalli > Assignee: Steven Hawkins > Priority: Major > Fix For: 11.0, 10.3.2 > > > When using Translator overwrite property enableDependentJoins with Redshift translator, we got the following error. > Caused by: java.sql.SQLException: [Amazon](500310) Invalid operation: CREATE TEMP TABLE ON COMMIT is not supported; at com.amazon.redshift.client.messages.inbound.ErrorResponse.toErrorException(ErrorResponse.java:1830) ... 30 lines omitted ... at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) Caused by: com.amazon.support.exceptions.ErrorException: [Amazon](500310) Invalid operation: CREATE TEMP TABLE ON COMMIT is not supported; ... 32 more -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5525) add a flag to revert to the prior behavior (TEIID-4557)

by Johnathon Lee (Jira)

[ https://issues.jboss.org/browse/TEIID-5525?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-5525: --------------------------------- Fix Version/s: 8.12.17.6_4 > add a flag to revert to the prior behavior (TEIID-4557) > ------------------------------------------------------- > > Key: TEIID-5525 > URL: https://issues.jboss.org/browse/TEIID-5525 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.14.6_4, 8.12.15.6_4 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Major > Fix For: 11.0.3, 11.1.2, 12.0, 11.2.1, 8.12.17.6_4 > > > Several customers are seeing errors[1] after https://issues.jboss.org/browse/TEIID-4557 was implemented and generally have to drop the max-active-plans to 1 for their queries to succeed. Can a flag be added to revert to the behavior prior to TEIID-4557? > [1] > ERROR [org.teiid.PROCESSOR] TEIID30019 Unexpected exception for request rcX003UtoyEg.0: org.teiid.core.TeiidComponentException: TEIID31261 Max estimated size 4,963,628,721 for a single operation/table id 85 has been exceeded. The server may need to increase the amount of disk or memory available, or decrease the number of max active plans. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5525) add a flag to revert to the prior behavior (TEIID-4557)

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5525?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5525: --------------------------------------- [~jolee] Options.enforceSingleMaxBufferSizeEstimate should also be false yes. > add a flag to revert to the prior behavior (TEIID-4557) > ------------------------------------------------------- > > Key: TEIID-5525 > URL: https://issues.jboss.org/browse/TEIID-5525 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.14.6_4, 8.12.15.6_4 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Major > Fix For: 11.0.3, 11.1.2, 12.0, 11.2.1 > > > Several customers are seeing errors[1] after https://issues.jboss.org/browse/TEIID-4557 was implemented and generally have to drop the max-active-plans to 1 for their queries to succeed. Can a flag be added to revert to the behavior prior to TEIID-4557? > [1] > ERROR [org.teiid.PROCESSOR] TEIID30019 Unexpected exception for request rcX003UtoyEg.0: org.teiid.core.TeiidComponentException: TEIID31261 Max estimated size 4,963,628,721 for a single operation/table id 85 has been exceeded. The server may need to increase the amount of disk or memory available, or decrease the number of max active plans. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5561) Prevent alias collisions with built-in odata schema

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5561?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5561: --------------------------------------- Also validate that vdb / model name handling of url reserved characters, and in general handling for table/procedure names containing '.'. > Prevent alias collisions with built-in odata schema > --------------------------------------------------- > > Key: TEIID-5561 > URL: https://issues.jboss.org/browse/TEIID-5561 > Project: Teiid > Issue Type: Quality Risk > Components: OData > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1 > > > It is problematic to have a Teiid model/schema with the name: > olingo-extensions > teiid > edm > as that will use an alias that conflicts with built-in handling. We should provide an error/warning as appropriate or come up with the logic to introduce a non-conflicting alias. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5563) Separate the Teiid connectors into their own repo

by Van Halbert (Jira)

[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ] Van Halbert reassigned TEIID-5563: ---------------------------------- Assignee: Van Halbert (was: Steven Hawkins) > Separate the Teiid connectors into their own repo > ------------------------------------------------- > > Key: TEIID-5563 > URL: https://issues.jboss.org/browse/TEIID-5563 > Project: Teiid > Issue Type: Task > Components: Build/Kits, Integration Tests > Affects Versions: 12.x > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Major > > Separate the Teiid connectors into their own repo to make it easier to manage the Teiid project dependencies separate from the connectors. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues December 2018