[JBoss JIRA] (TEIID-5557) Restrict imports to a single schema
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5557?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5557:
---------------------------------------
For 12.0 added info messages to start with about the potential default change for useFullSchemaName and the recommendation to import from only a single schema.
> Restrict imports to a single schema
> -----------------------------------
>
> Key: TEIID-5557
> URL: https://issues.jboss.org/browse/TEIID-5557
> Project: Teiid
> Issue Type: Quality Risk
> Components: Connector API
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.x, 13.0
>
>
> To better align with SQL/MED and to simplify legacy import properties it would be best to restrict foreign imports to a single schema. This will remove quite a bit of confusion around potential duplicate object names.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months