May 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3465) mongoDB: Update Metadata processor to handle nested documents

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-3465: ----------------------------------- Summary: mongoDB: Update Metadata processor to handle nested documents Key: TEIID-3465 URL: https://issues.jboss.org/browse/TEIID-3465 Project: Teiid Issue Type: Enhancement Components: Misc. Connectors Affects Versions: 8.10 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Teiid 8.10 version provided a detailed support for the nested documents in MongoDB based on the schema and extension properties provided. However when reading the existing JSON documents from MongoDB to figure out the compatible schema, it is not updated to recognize all the possible nesting in JSON document to produce a correct schema. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3422) Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3422?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3422: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1210577|https://bugzilla.redhat.com/show_bug.cgi?id=1210577] from MODIFIED to ON_QA > Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize() > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-3422 > URL: https://issues.jboss.org/browse/TEIID-3422 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Environment: JBoss DV 6.0, 6.1 > Reporter: hisao furuichi > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize(). > One of our user needs to set more than 512MB for buffer-service-max-storage-object-size to avoid TEIID30001[1], this limitation becomes a critical issue for them. > Additional Information: > By taking look at the source code[2], if the value of maxStorageObjectSize is more than equals with 536870912, the loop becomes infinit, and will cause OOME. > [1] > TEIID30001 Max block number exceeded by 233,144 21,422,155. Increase the maxStorageObjectSize to support larger storage objects. Alternatively you could make the processor batch size smaller. > [2]teiid/engine/src/main/java/org/teiid/common/buffer/impl/BufferFrontedFileStoreCache.java > === > public static final long MAX_ADDRESSABLE_MEMORY = 1l<<(ADDRESS_BITS+LOG_BLOCK_SIZE); > ~~ > static final int BLOCK_SIZE = 1 << LOG_BLOCK_SIZE; > ~~ > public void initialize() throws TeiidComponentException { > ~~ > List<BlockStore> stores = new ArrayList<BlockStore>(); > int size = BLOCK_SIZE; > int files = 32; //this allows us to have 64 terabytes of smaller block sizes > do { > stores.add(new BlockStore(this.storageManager, size, 30, files)); > size <<=1; > if (files > 1) { > files >>= 1; > } > } while ((size>>1) < maxStorageObjectSize); > ~~ > === -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3324) Boolean fields with null are evaluated to false

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3324?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3324: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1206576|https://bugzilla.redhat.com/show_bug.cgi?id=1206576] from MODIFIED to ON_QA > Boolean fields with null are evaluated to false > ----------------------------------------------- > > Key: TEIID-3324 > URL: https://issues.jboss.org/browse/TEIID-3324 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 7.1 > Reporter: Salvatore R > Assignee: Steven Hawkins > Fix For: 8.10, 8.7.2, 8.7.1.6_2 > > > I have a source table defined as follows (e.g. in PostgreSQL): > {code:sql} > CREATE TABLE public.test > ( > id integer, > iscustomer boolean > ) > {code} > and the table contains these rows: > {code:sql} > insert into public.test values(1, null); > insert into public.test values(2, true); > insert into public.test values(3, false); > {code} > > When I try to get data from this table in Teiid, the "null" value is evaluated as false: > ||id||iscustomer|| > |1|false| > |2|true| > |3|false| -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3296: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1207222|https://bugzilla.redhat.com/show_bug.cgi?id=1207222] from MODIFIED to ON_QA > Some criteria are missing when indexes are used on the source tables > -------------------------------------------------------------------- > > Key: TEIID-3296 > URL: https://issues.jboss.org/browse/TEIID-3296 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.2 > Reporter: Salvatore R > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.10, 8.7.2, 8.7.1.6_2 > > > The following two tables are defined in two different datasources (PostgreSQL and MySQL): > {code:sql} > CREATE TABLE "pg"."tx1" > ( > a varchar(2147483647), > b varchar(2147483647), > c integer, > d integer, > e integer > ); > CREATE INDEX tx1_b ON "pg"."tx1"(b); > CREATE INDEX tx1_a ON "pg"."tx1"(a); > CREATE INDEX tx1_e ON "pg"."tx1"(e); > CREATE INDEX tx1_d ON "pg"."tx1"(d); > CREATE INDEX tx1_c ON "pg"."tx1"(c); > > CREATE TABLE "my"."tx2" > ( > a integer, > b integer, > c integer, > d integer, > e integer > ); > insert into tx1 VALUES(1,1,1,1,1) ; > insert into tx1 VALUES(1,2,2,2,2) ; > insert into tx1 VALUES(1,2,3,3,3) ; > insert into tx1 VALUES(1,2,3,4,4) ; > insert into tx1 VALUES(1,2,3,4,5) ; > insert into tx2 VALUES(1,2,3,4,5) ; > {code} > Running the following query: > {code:sql} > select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e; > {code} > a wrong result is returned: > ||a||b||c||d||e|| > |1|2|2|2|2| > |1|2|3|3|3| > |1|2|3|4|4| > If indexes are removed from the source table, the expected result is correctly returned: > ||a||b||c||d||e|| > |1|2|3|4|4| -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3279) SOLR: Error when date, time or timestamp literal is in where clause

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3279?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3279: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1180107|https://bugzilla.redhat.com/show_bug.cgi?id=1180107] from MODIFIED to ON_QA > SOLR: Error when date,time or timestamp literal is in where clause > ------------------------------------------------------------------ > > Key: TEIID-3279 > URL: https://issues.jboss.org/browse/TEIID-3279 > Project: Teiid > Issue Type: Bug > Components: Connector API > Affects Versions: 8.7 > Reporter: Filip Elias > Assignee: Ramesh Reddy > Labels: Beta1 > Fix For: 8.7.1, 8.10 > > > Query fails when time,date or timestamp literal is used in where clause. > Examples: > Query: > {code}select intkey from smalla where timevalue = '11:30:20'{code} > Error: > {code} > '11:30:20'org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'11-30-20' > at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491) > {code} > Query: > {code}select intkey from smalla where datevalue = '2002-02-02'{code} > Error: > {code} > org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'11-30-20' > at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491) > {code} > Query: > {code}select intkey from smalla where timestampvalue = '2000-01-01 00:00:04'{code} > Error: > {code} org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'2000-01-01T00-00-04' > at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491) > {code} > SOLR supports only timestamps (YYYY-mm-ddThh:mm:ssZ) so date and time types should be converted into timestamp before a query is send to SOLR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3418) Allow positional group by for odbc

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3418?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3418: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1211342|https://bugzilla.redhat.com/show_bug.cgi?id=1211342] from MODIFIED to ON_QA > Allow positional group by for odbc > ---------------------------------- > > Key: TEIID-3418 > URL: https://issues.jboss.org/browse/TEIID-3418 > Project: Teiid > Issue Type: Quality Risk > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > A remaining item for TEIID-3073 was that since tableau assumes we are postgresql they will use the pg specific positional group by references. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3438) Null value returned from BlobImpl getBytes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3438?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3438: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1212852|https://bugzilla.redhat.com/show_bug.cgi?id=1212852] from MODIFIED to ON_QA > Null value returned from BlobImpl getBytes > ------------------------------------------ > > Key: TEIID-3438 > URL: https://issues.jboss.org/browse/TEIID-3438 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.7 > Reporter: Kylin Soong > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.10.1, 8.11 > > Attachments: TEIID-3438.zip > > > If translator retrieveValue return a empty Blob, the engine will throw NPE as below > Caused by: java.lang.NullPointerException > at javax.sql.rowset.serial.SerialBlob.<init>(SerialBlob.java:100) > at org.teiid.common.buffer.LobManager.persistLob(LobManager.java:226) > at org.teiid.common.buffer.LobManager.updateReferences(LobManager.java:141) > at org.teiid.common.buffer.TupleBuffer.addTupleBatch(TupleBuffer.java:203) > at org.teiid.query.processor.BatchCollector.flushBatchDirect(BatchCollector.java:229) > at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:653) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3404) Teiid DatabaseAppender JPA perisist Command log consume high CPU

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3404?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3404: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1206143|https://bugzilla.redhat.com/show_bug.cgi?id=1206143] from MODIFIED to ON_QA > Teiid DatabaseAppender JPA perisist Command log consume high CPU > ---------------------------------------------------------------- > > Key: TEIID-3404 > URL: https://issues.jboss.org/browse/TEIID-3404 > Project: Teiid > Issue Type: Bug > Components: Tools > Affects Versions: 8.7.1 > Environment: * DV 6.1 > * dynamicvdb-datafederation quickstart > Reporter: Kylin Soong > Assignee: Kylin Soong > Fix For: 8.7.2 > > > I have 4 - 5 concurrent client query to Portfolio VDB, this cause log DatabaseAppender JPA perisist Command log thread consume high CPU. In my test, one log threads always swallow high CPU, if the concurrent client query more than 10, it swallow 100% cpu. > [1] have detailed reproduce steps, including thread dumps. > [1] https://github.com/kylinsoong/teiid-samples/tree/master/command-logging-h... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3296: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1206573|https://bugzilla.redhat.com/show_bug.cgi?id=1206573] from MODIFIED to ON_QA > Some criteria are missing when indexes are used on the source tables > -------------------------------------------------------------------- > > Key: TEIID-3296 > URL: https://issues.jboss.org/browse/TEIID-3296 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.2 > Reporter: Salvatore R > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.10, 8.7.2, 8.7.1.6_2 > > > The following two tables are defined in two different datasources (PostgreSQL and MySQL): > {code:sql} > CREATE TABLE "pg"."tx1" > ( > a varchar(2147483647), > b varchar(2147483647), > c integer, > d integer, > e integer > ); > CREATE INDEX tx1_b ON "pg"."tx1"(b); > CREATE INDEX tx1_a ON "pg"."tx1"(a); > CREATE INDEX tx1_e ON "pg"."tx1"(e); > CREATE INDEX tx1_d ON "pg"."tx1"(d); > CREATE INDEX tx1_c ON "pg"."tx1"(c); > > CREATE TABLE "my"."tx2" > ( > a integer, > b integer, > c integer, > d integer, > e integer > ); > insert into tx1 VALUES(1,1,1,1,1) ; > insert into tx1 VALUES(1,2,2,2,2) ; > insert into tx1 VALUES(1,2,3,3,3) ; > insert into tx1 VALUES(1,2,3,4,4) ; > insert into tx1 VALUES(1,2,3,4,5) ; > insert into tx2 VALUES(1,2,3,4,5) ; > {code} > Running the following query: > {code:sql} > select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e; > {code} > a wrong result is returned: > ||a||b||c||d||e|| > |1|2|2|2|2| > |1|2|3|3|3| > |1|2|3|4|4| > If indexes are removed from the source table, the expected result is correctly returned: > ||a||b||c||d||e|| > |1|2|3|4|4| -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3443) wrong estimation of BufferFrontedFileStoreCache.maxMemoryBlocks

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3443?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3443: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1212731|https://bugzilla.redhat.com/show_bug.cgi?id=1212731] from MODIFIED to ON_QA > wrong estimation of BufferFrontedFileStoreCache.maxMemoryBlocks > --------------------------------------------------------------- > > Key: TEIID-3443 > URL: https://issues.jboss.org/browse/TEIID-3443 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.4, 8.10 > Environment: JDV 6.0.x, 6.1.0 > Reporter: Hisanobu Okuda > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > BufferFrontedFileStoreCache.maxMemoryBlocks is under-estimated. For example, when max-storage-object-size=8000000, maxMemoryBlocks > is 488 at the line #575 in org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize() (after that, it is decrimented some times, but it does not matter). > {code} > main[1] run > > > Breakpoint hit: "thread=MSC service thread 1-3", org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize(), line=573 bci=163 > 573 maxMemoryBlocks = Math.min(maxMemoryBlocks, maxStorageObjectSize>>LOG_BLOCK_SIZE + ((maxStorageObjectSize&BufferFrontedFileStoreCache.BLOCK_MASK)>0?1:0)); > MSC service thread 1-3[1] next > > > Step completed: "thread=MSC service thread 1-3", org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize(), line=575 bci=198 > 575 cleaningThreshold = Math.min(maxMemoryBlocks<<4, blocks>>1); > MSC service thread 1-3[1] dump this > this = { > ...snip... > maxStorageObjectSize: 8000000 > ...snip... > maxMemoryBlocks: 488 > {code} > An actual cache object size for maxMemoryBlocks: 488 is roughly:- > {code} > 8192 * 488 = 3997696 > {code} > It is less than half of maxStorageObjectSize. It sometimes causes TEIID30001. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2015