April 2015 - teiid-issues - Jboss List Archives

[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 NEW to MODIFIED > 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: 6.2-8.7.2, 8.10.1, 8.11 > > > 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.11#6341)

9 years, 8 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3443?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3443: ---------------------------------- Fix Version/s: 6.2-8.7.2 > 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: 6.2-8.7.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.11#6341)

9 years, 8 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3438?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3438: ---------------------------------- Fix Version/s: 6.2-8.7.2 > 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: 6.2-8.7.2, 8.10.1, 8.11 > > > 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.11#6341)

9 years, 8 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 updated TEIID-3438: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1212852 > 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.10.1, 8.11 > > > 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.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3359) Allow more control over odata layer caching

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3359?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3359: --------------------------------------- > I think the simplest option would be to allow a cache hint as a ReST query parameter Now that we have forked OData4j that may be possible, but I'm not sure how that would work with Olingo. Perhaps just relying on something more fundamental like TEIID-3434 would work. > Allow more control over odata layer caching > ------------------------------------------- > > Key: TEIID-3359 > URL: https://issues.jboss.org/browse/TEIID-3359 > Project: Teiid > Issue Type: Enhancement > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 8.11 > > > The caching is always performed at a user level and for each query. Consumers may need to localize the caching affect only to paging results and scope only to that interaction, rather than for all users. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3442) Apache Spark support via SparkSQL and DataFrames

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3442?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-3442: ------------------------------------- Fix Version/s: Open To Community (was: 9.x) Assignee: (was: Steven Hawkins) > Apache Spark support via SparkSQL and DataFrames > ------------------------------------------------ > > Key: TEIID-3442 > URL: https://issues.jboss.org/browse/TEIID-3442 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 8.10 > Reporter: John Muller > Labels: Connectors, Spark, Translators > Fix For: Open To Community > > Original Estimate: 20 weeks > Remaining Estimate: 20 weeks > > Eliciting comments for Apache Spark support. With the release of Panda's like DataFrames, it is a little more feasible to directly translate to SparkSQL: > https://spark.apache.org/docs/latest/sql-programming-guide.html > Options in order of complexity: > 1. Use the existing Hive connector / translator. Spark still uses the Hive metastore. > 2. Thrift JDBC driver. This is what Microstrategy, Tableau, QlikView and others use, most rudimentary API for accessing Spark. > 3. Native SparkSQL via building Spark jobs and submitting them to a running Spark driver. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3443?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3443. ----------------------------------- Fix Version/s: 8.11 Resolution: Done This could be considered for backport or the workaround of using a block aligned value could be used. > 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.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.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3441) XMLParse should allow varbinary as well

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3441?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3441. ----------------------------------- Resolution: Done Added varbinary support and some tests with byte order marks. > XMLParse should allow varbinary as well > --------------------------------------- > > Key: TEIID-3441 > URL: https://issues.jboss.org/browse/TEIID-3441 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Minor > Fix For: 8.11 > > > XMLParse accepts blob and character types. It should also accept varbinary. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

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

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3443?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3443: --------------------------------------- The issue is that + in expression has higher precedence - which give this issue for values of the maxMemoryBlocks that are not aligned with the block size. So any value divisible by 8kb will be fine. > 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 > > 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.11#6341)

9 years, 8 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 updated TEIID-3443: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1212731 > 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 > > 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.11#6341)

9 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2015