[JBoss JIRA] (TEIID-2460) Weird behavior when Max buffer space restriction is hit
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2460:
----------------------------------
Component/s: Query Engine
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
> Attachments: teiid-jboss-beans.xml
>
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2455) Cannot execute SQL query using SQL function in SORT clause via view model
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2455?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2455:
---------------------------------------
Thanks Eiichi for catching this. Updated the fix for alpha2 by moving the restoration of the project after the child assignment, which corrects issues when the unrelated columns as not projected.
> Cannot execute SQL query using SQL function in SORT clause via view model
> -------------------------------------------------------------------------
>
> Key: TEIID-2455
> URL: https://issues.jboss.org/browse/TEIID-2455
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7.4
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> If SQL query is contained using SQL function in SORT clause, the query cannot execute via view model.
> ex) SELECT C1 FROM TEST_TABLE_VW order by CAST(C3 AS integer)
> Version-Release number of selected component (if applicable):
> EDS 5.3.1
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2460) Weird behavior when Max buffer space restriction is hit
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2460:
---------------------------------------
I think this should be improved, but it does not need to hold up the 7.7.6. As it still appears to me that normal operation resumes after an offending tuplebuffer references have been cleaned up. Also the intent of the space limit is just a stop gap to prevent run-away disk usage - the feature was not designed nor required to immediately and gracefully handle the situation.
There are a couple of things to do:
1. Not log the full stacktrace at the error level when an exception is caught moving a batch out of the memory buffer
2. Proactively remove the entire cache group if the move fails
3. Address TEIID-2430 (which will probably be tied to the command context)
4. See if we can even more proactively interrupt a process that has lost a batch (which would undo the assumption that the situation may be recoverable).
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
> Attachments: teiid-jboss-beans.xml
>
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2457) Assertion error with INTERSECT
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2457?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2457.
-----------------------------------
Resolution: Done
Corrected the removal so that the sort method is safe to call multiple times.
> Assertion error with INTERSECT
> ------------------------------
>
> Key: TEIID-2457
> URL: https://issues.jboss.org/browse/TEIID-2457
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.3, 7.7.6
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4
>
>
> A sample query which produced the error is: SELECT IntKey FROM BQT1.SmallA INTERSECT SELECT IntNum FROM BQT1.SmallB ORDER BY INTKEY
> How to reproduce: Run the query using a client such as Squirrel multiple times. The results varies from returning an Assertion to returning actual results. In my test I ran the query five times and it returned actual results twice and the Assertion 3 times. The Assertion can be seen below.
> 2013-04-03 16:00:42,190 ERROR [org.teiid.PROCESSOR] (Worker4_QueryProcessorQueue146) Unexpected exception for request JyDs6MZ6d9zG.24
> java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> at org.teiid.common.buffer.TupleBuffer.getBatch(TupleBuffer.java:217)
> at org.teiid.common.buffer.TupleBuffer$1.getBatch(TupleBuffer.java:331)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:61)
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:91)
> at org.teiid.query.processor.relational.MergeJoinStrategy.process(MergeJoinStrategy.java:163)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:212)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:70)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:69)
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:85)
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48)
> at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:248)
> at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:185)
> at org.teiid.query.processor.relational.SortNode.sortPhase(SortNode.java:99)
> at org.teiid.query.processor.relational.SortNode.nextBatchDirect(SortNode.java:88)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.relational.LimitNode.nextBatchDirect(LimitNode.java:100)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:176)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:139)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:105)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:147)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:375)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:288)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:216)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:244)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:122)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:292)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2457) Assertion error with INTERSECT
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2457?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2457:
----------------------------------
Fix Version/s: 8.4
Priority: Critical (was: Major)
Affects Version/s: 8.3
This is a regression with TEIID-2363 - if a prefetch against a right source that is being sorted completes the sort, then the subsequent call to load the right will remove the needed sorted buffer and an exception like the one shown on this issue will occur.
> Assertion error with INTERSECT
> ------------------------------
>
> Key: TEIID-2457
> URL: https://issues.jboss.org/browse/TEIID-2457
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.3, 7.7.6
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4
>
>
> A sample query which produced the error is: SELECT IntKey FROM BQT1.SmallA INTERSECT SELECT IntNum FROM BQT1.SmallB ORDER BY INTKEY
> How to reproduce: Run the query using a client such as Squirrel multiple times. The results varies from returning an Assertion to returning actual results. In my test I ran the query five times and it returned actual results twice and the Assertion 3 times. The Assertion can be seen below.
> 2013-04-03 16:00:42,190 ERROR [org.teiid.PROCESSOR] (Worker4_QueryProcessorQueue146) Unexpected exception for request JyDs6MZ6d9zG.24
> java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> at org.teiid.common.buffer.TupleBuffer.getBatch(TupleBuffer.java:217)
> at org.teiid.common.buffer.TupleBuffer$1.getBatch(TupleBuffer.java:331)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:61)
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:91)
> at org.teiid.query.processor.relational.MergeJoinStrategy.process(MergeJoinStrategy.java:163)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:212)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:70)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:69)
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:85)
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48)
> at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:248)
> at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:185)
> at org.teiid.query.processor.relational.SortNode.sortPhase(SortNode.java:99)
> at org.teiid.query.processor.relational.SortNode.nextBatchDirect(SortNode.java:88)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.relational.LimitNode.nextBatchDirect(LimitNode.java:100)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:176)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:139)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:105)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:147)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:375)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:288)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:216)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:244)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:122)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:292)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2460) Weird behavior when Max buffer space restriction is hit
by Filip Nguyen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Filip Nguyen commented on TEIID-2460:
-------------------------------------
I will retest on 8.4 and try to wait for reclaim of the disk space.
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
> Attachments: teiid-jboss-beans.xml
>
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2460) Weird behavior when Max buffer space restriction is hit
by Filip Nguyen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Filip Nguyen updated TEIID-2460:
--------------------------------
Attachment: teiid-jboss-beans.xml
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
> Attachments: teiid-jboss-beans.xml
>
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2460) Weird behavior when Max buffer space restriction is hit
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2460:
---------------------------------------
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
The plan or asynch thread processing the eviction to disk will likely not be the owner of the given batch, thus we log that the problem occurred and don't take immediate action - we are also ideally in a scenario where the plan will not need that particular batch or it's recoverable via a weak reference. Only when the plan requests a batch that is no longer available do we throw back the exception and cleanup. The delay between when the batch is dropped and when the plan needs it should be no different than in normal processing (and appears to work that way for me on 8.4).
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
I don't see this on 8.4 either. However at worst this may be up to the platform related. If we don't have an immediate removal of defunct TupleBuffers, it is up to garage collection to trigger the cleanup. So you could for example be hitting https://issues.jboss.org/browse/TEIID-2430 but even then you should see the space being reclaimed in a relatively short time.
Can you retest on 8.4?
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2460) Weird behavior when Max buffer space restriction is hit
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2460:
---------------------------------------
Can you provide the full buffer configuration or teiid-jboss-beans?
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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
11 years, 2 months
[JBoss JIRA] (TEIID-2460) Weird behavior when Max buffer space restriction is hit
by Filip Nguyen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Filip Nguyen updated TEIID-2460:
--------------------------------
Steps to Reproduce:
Create a text data source.
Create a dynamic VDB with file translator to that data source.
create a big text file:
for i in \{1..1000};do echo "1" >> result0;done
for i in \{1..8};do cat * > result$\{i};done
cat * > textfile
rm result*
configure the buffer manager: teiid-jboss-beans.xml
run query via JDBC: ./run.sh localhost 31000 FileTest "SELECT tex.first from (call getTextFiles('textfile')) as file, TEXTTABLE(file COLUMNS first integer) as tex order by tex.first desc"
was:
Create a text data source.
Create a dynamic VDB with file translator to that data source.
create a big text file:
for i in \{1..1000};do echo "1" >> result0;done
for i in \{1..8};do cat * > result$\{i};done
cat * > textfile
rm result*
configure the buffer manager: /home/fnguyen/work/edsqa/bz907640/jboss-soa-p-5/jboss-as/server/production/deploy/teiid/teiid-jboss-beans.xml
run query via JDBC: ./run.sh localhost 31000 FileTest "SELECT tex.first from (call getTextFiles('textfile')) as file, TEXTTABLE(file COLUMNS first integer) as tex order by tex.first desc"
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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
11 years, 2 months