March 2014 - teiid-issues - Jboss List Archives

[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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[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 reopened TEIID-2826: --------------------------------- Embeeded seems to be having issues with dependencies with this version, the download size way too huge > 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, 3 months

1
0
0 / 0

[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, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2329) Add support for Mongo DB as a data source

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2329?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2329: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 888935|https://bugzilla.redhat.com/show_bug.cgi?id=888935] from VERIFIED to CLOSED > Add support for Mongo DB as a data source > ----------------------------------------- > > Key: TEIID-2329 > URL: https://issues.jboss.org/browse/TEIID-2329 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Van Halbert > Assignee: Ramesh Reddy > Fix For: 8.4, Open To Community > > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2361) The current MAX String size is 4000, add the ability to configure when larger sizes are used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2361?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2361: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 896305|https://bugzilla.redhat.com/show_bug.cgi?id=896305] from VERIFIED to CLOSED > The current MAX String size is 4000, add the ability to configure when larger sizes are used > -------------------------------------------------------------------------------------------- > > Key: TEIID-2361 > URL: https://issues.jboss.org/browse/TEIID-2361 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 8.3, 7.7.7 > > > The MAX String size is currently 4000. After a discussion with Steve, he indicated a more common default might be 16k, and also add the ability to configure the size when a data source is being used that contains large sizes. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2683) Proactive eviction of new batches reduces forward-only performance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2683?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2683: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1015232|https://bugzilla.redhat.com/show_bug.cgi?id=1015232] from VERIFIED to CLOSED > Proactive eviction of new batches reduces forward-only performance > ------------------------------------------------------------------ > > Key: TEIID-2683 > URL: https://issues.jboss.org/browse/TEIID-2683 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Affects Versions: 8.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.6 > > > With TEIID-2429 to improve performance under heavy buffer load the cleaner was made more proactive in evicting new batches. In streaming scenarios this results in a lot of unnecessary buffering as the batches are likely to be held only for a short time. -- 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, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2014