[JBoss JIRA] (TEIID-2890) IndexOutOfBoundsException when using GROUP BY
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2890?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2890:
----------------------------------
Fix Version/s: 8.7
Priority: Major (was: Minor)
Affects Version/s: 8.4
(was: 8.7)
This seemed to be reproducible for me back to 8.4. Although that was using the repository versions, rather than finals so I'm not sure if there could have been a patch regression to explain why you didn't see this on 8.6. In any case the issue is the indexing logic in the grouping node assumes that each order by expression is unique, which is something that we don't enforce.
> IndexOutOfBoundsException when using GROUP BY
> ---------------------------------------------
>
> Key: TEIID-2890
> URL: https://issues.jboss.org/browse/TEIID-2890
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Reporter: Tom Arnold
> Assignee: Steven Hawkins
> Labels: 8.7, grouping, translator
> Fix For: 8.7
>
>
> I have a translator that does not support aggregates or grouping. I am using a view to try to normalize data from several sources. I am duplicating some of the fields as an approximation. I have existing software that is querying with GROUP BY, and sometimes this happens.
> This query works fine in 8.6:
> {code:sql}
> select identifier
> from foo.items
> group by identifier, identifier;
> {code}
> In 8.7 this happens:
> {code}
> 10:15:24,280 ERROR [org.teiid.PROCESSOR] (Worker2_QueryProcessorQueue39) njknuxobPkVY TEIID30019 Unexpected exception for request njknuxobPkVY.3: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:604) [rt.jar:1.7.0_02]
> at java.util.ArrayList.get(ArrayList.java:382) [rt.jar:1.7.0_02]
> at org.teiid.query.processor.relational.MergeJoinStrategy.compareTuples(MergeJoinStrategy.java:313) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.GroupingNode.sameGroup(GroupingNode.java:488) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.GroupingNode.groupPhase(GroupingNode.java:414) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.GroupingNode.nextBatchDirect(GroupingNode.java:336) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:159) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:141) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:273) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_02]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_02]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_02]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Patrick Deenen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Patrick Deenen updated TEIID-2892:
----------------------------------
Attachment: logfiles.zip
The log files with my query tests
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Patrick Deenen (JIRA)
Patrick Deenen created TEIID-2892:
-------------------------------------
Summary: OData buffers ALL rows from resultset before returning the first batch
Key: TEIID-2892
URL: https://issues.jboss.org/browse/TEIID-2892
Project: Teiid
Issue Type: Bug
Components: OData
Affects Versions: 8.4.1
Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
Reporter: Patrick Deenen
Assignee: Steven Hawkins
OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
Attached you can find two log files which show the problem.
The Odata query used is:
http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
Which is identical to the JDBC query used:
select * from event_fact where event_fact_id between 747000000 and 747200000;
In both cases the result contains 200.000 rows
ODATA log information analysis (log file ’server start + odata batch 256.log’):
row 4543 - 4657 - Start query
row 4658 - 9030 - Read ALL results from result set and store them in buffer
row 9031 - 9035 - Close DB connection
row 9036 - 14647 - Clean buffers and create response?
row 14648 - 14661 - return first batch and close connection
JDBC log information analysis (log file ’server start + jdbc.log’):
row 4925 - 5112 - Start query
row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
row 5157 - 5214 - Close DB connection
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2863:
----------------------------------
Attachment: auth.patch
What about something like the attached? This would avoid the notion of an ANY authentication type and allows the vdb to override all settings related to authentication.
We also need a compatibility issue in the release notes as we are only supporting a single security domain on the transport setting. But from what I can see with JBossSessionService if there is only a single security domain set on the transport, then that is the only one the service will know about. Setting a different security domain in a vdb seems like it will fail.
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Attachments: auth.patch
>
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (TEIID-2826) Change build to use zip translator packaging when building jboss kit
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2826?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-2826.
---------------------------------
Resolution: Done
Added embedded kit as similar to jboss-as7 kit. I still some dependency in the definition of the dependencies in "cassandra", "simpledb", "google" as they require additional dependency sets, typically these need to be driven by the pom.xml and set transitive dependencies to false. That is for another day!
> Change build to use zip translator packaging when building jboss kit
> --------------------------------------------------------------------
>
> Key: TEIID-2826
> URL: https://issues.jboss.org/browse/TEIID-2826
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Affects Versions: 8.7
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Labels: Beta2
> Fix For: 8.7
>
>
> Change build to use zip translator packaging when building jboss kit
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (TEIID-2889) MongoDB translator fails to deploy
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2889?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-2889.
---------------------------------
Labels: 8.7 Beta2 mongodb (was: 8.7 mongodb)
Fix Version/s: 8.7
Resolution: Done
Looks like bug with the version the assembly maven plug-in. Updated to version 2.4 to fix the bug
> MongoDB translator fails to deploy
> ----------------------------------
>
> Key: TEIID-2889
> URL: https://issues.jboss.org/browse/TEIID-2889
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.7
> Reporter: Tom Arnold
> Assignee: Ramesh Reddy
> Labels: 8.7, mongodb, Beta2
> Fix For: 8.7
>
>
> I am building Teiid from GIT master. I noticed that the MongoDB translator failed to deploy. Upon further investigation I found that the module.xml was looking for a different version of the MongoDB Java driver than what was packaged.
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.0" name="org.jboss.teiid.translator.mongodb.api">
> <resources>
> <resource-root path="mongodb-api-8.7.0.Beta2-SNAPSHOT.jar" />
> <resource-root path="mongo-java-driver-2.11.1.jar" />
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.resource.api"/>
> <module name="org.jboss.teiid.common-core" />
> <module name="org.jboss.teiid.api" />
> </dependencies>
> </module>
> {code}
>
> {code}
> mongo-java-driver-2.7.3.jar
> {code}
> {code}
> git clean -fdx
> git reset --hard
> mvn clean install -P release -s settings.xml -DskipTests
> {code}
> Building just the translator, I see that 2.11.1 and 2.7.3 get pulled down. I've been doing greps and cannot find what is pulling in the older version.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months