[jira] [Updated] (DRILL-5083) RecordIterator can sometimes restart a query on close
[ https://issues.apache.org/jira/browse/DRILL-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kulyk updated DRILL-5083: --- Attachment: Reproduce5083.jpg > RecordIterator can sometimes restart a query on close > - > > Key: DRILL-5083 > URL: https://issues.apache.org/jira/browse/DRILL-5083 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Paul Rogers >Assignee: Roman Kulyk >Priority: Minor > Labels: ready-to-commit > Fix For: 1.11.0 > > Attachments: DrillOperatorErrorHandlingRedesign.pdf, Reproduce5083.jpg > > > This one is very confusing... > In a test with a MergeJoin and external sort, operators are stacked something > like this: > {code} > Screen > - MergeJoin > - - External Sort > ... > {code} > Using the injector to force a OOM in spill, the external sort threw a > UserException up the stack. This was handed by: > {code} > IteratorValidatorBatchIterator.next( ) > RecordIterator.clearInflightBatches( ) > RecordIterator.close( ) > MergeJoinBatch.close( ) > {code} > Which does the following: > {code} > // Check whether next() should even have been called in current state. > if (null != exceptionState) { > throw new IllegalStateException( > {code} > But, the exceptionState is set, so we end up throwing an > IllegalStateException during cleanup. > Seems the code should agree: if {{next( )}} will be called during cleanup, > then {{next( )}} should gracefully handle that case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DRILL-5083) RecordIterator can sometimes restart a query on close
[ https://issues.apache.org/jira/browse/DRILL-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kunal Khatua updated DRILL-5083: Reviewer: Khurram Faraaz (was: Paul Rogers) [~khfaraaz] Can you verify if this issue is resolved with DRILL-5599 (Drill 1.11.0)? > RecordIterator can sometimes restart a query on close > - > > Key: DRILL-5083 > URL: https://issues.apache.org/jira/browse/DRILL-5083 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Paul Rogers >Assignee: Roman >Priority: Minor > Labels: ready-to-commit > Fix For: 1.11.0 > > Attachments: DrillOperatorErrorHandlingRedesign.pdf > > > This one is very confusing... > In a test with a MergeJoin and external sort, operators are stacked something > like this: > {code} > Screen > - MergeJoin > - - External Sort > ... > {code} > Using the injector to force a OOM in spill, the external sort threw a > UserException up the stack. This was handed by: > {code} > IteratorValidatorBatchIterator.next( ) > RecordIterator.clearInflightBatches( ) > RecordIterator.close( ) > MergeJoinBatch.close( ) > {code} > Which does the following: > {code} > // Check whether next() should even have been called in current state. > if (null != exceptionState) { > throw new IllegalStateException( > {code} > But, the exceptionState is set, so we end up throwing an > IllegalStateException during cleanup. > Seems the code should agree: if {{next( )}} will be called during cleanup, > then {{next( )}} should gracefully handle that case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DRILL-5083) RecordIterator can sometimes restart a query on close
[ https://issues.apache.org/jira/browse/DRILL-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-5083: Labels: ready-to-commit (was: ) > RecordIterator can sometimes restart a query on close > - > > Key: DRILL-5083 > URL: https://issues.apache.org/jira/browse/DRILL-5083 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Paul Rogers >Assignee: Roman >Priority: Minor > Labels: ready-to-commit > Fix For: 1.11.0 > > Attachments: DrillOperatorErrorHandlingRedesign.pdf > > > This one is very confusing... > In a test with a MergeJoin and external sort, operators are stacked something > like this: > {code} > Screen > - MergeJoin > - - External Sort > ... > {code} > Using the injector to force a OOM in spill, the external sort threw a > UserException up the stack. This was handed by: > {code} > IteratorValidatorBatchIterator.next( ) > RecordIterator.clearInflightBatches( ) > RecordIterator.close( ) > MergeJoinBatch.close( ) > {code} > Which does the following: > {code} > // Check whether next() should even have been called in current state. > if (null != exceptionState) { > throw new IllegalStateException( > {code} > But, the exceptionState is set, so we end up throwing an > IllegalStateException during cleanup. > Seems the code should agree: if {{next( )}} will be called during cleanup, > then {{next( )}} should gracefully handle that case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DRILL-5083) RecordIterator can sometimes restart a query on close
[ https://issues.apache.org/jira/browse/DRILL-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-5083: Fix Version/s: 1.11.0 > RecordIterator can sometimes restart a query on close > - > > Key: DRILL-5083 > URL: https://issues.apache.org/jira/browse/DRILL-5083 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Paul Rogers >Assignee: Roman >Priority: Minor > Labels: ready-to-commit > Fix For: 1.11.0 > > Attachments: DrillOperatorErrorHandlingRedesign.pdf > > > This one is very confusing... > In a test with a MergeJoin and external sort, operators are stacked something > like this: > {code} > Screen > - MergeJoin > - - External Sort > ... > {code} > Using the injector to force a OOM in spill, the external sort threw a > UserException up the stack. This was handed by: > {code} > IteratorValidatorBatchIterator.next( ) > RecordIterator.clearInflightBatches( ) > RecordIterator.close( ) > MergeJoinBatch.close( ) > {code} > Which does the following: > {code} > // Check whether next() should even have been called in current state. > if (null != exceptionState) { > throw new IllegalStateException( > {code} > But, the exceptionState is set, so we end up throwing an > IllegalStateException during cleanup. > Seems the code should agree: if {{next( )}} will be called during cleanup, > then {{next( )}} should gracefully handle that case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DRILL-5083) RecordIterator can sometimes restart a query on close
[ https://issues.apache.org/jira/browse/DRILL-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-5083: Reviewer: Paul Rogers > RecordIterator can sometimes restart a query on close > - > > Key: DRILL-5083 > URL: https://issues.apache.org/jira/browse/DRILL-5083 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Paul Rogers >Assignee: Roman >Priority: Minor > Attachments: DrillOperatorErrorHandlingRedesign.pdf > > > This one is very confusing... > In a test with a MergeJoin and external sort, operators are stacked something > like this: > {code} > Screen > - MergeJoin > - - External Sort > ... > {code} > Using the injector to force a OOM in spill, the external sort threw a > UserException up the stack. This was handed by: > {code} > IteratorValidatorBatchIterator.next( ) > RecordIterator.clearInflightBatches( ) > RecordIterator.close( ) > MergeJoinBatch.close( ) > {code} > Which does the following: > {code} > // Check whether next() should even have been called in current state. > if (null != exceptionState) { > throw new IllegalStateException( > {code} > But, the exceptionState is set, so we end up throwing an > IllegalStateException during cleanup. > Seems the code should agree: if {{next( )}} will be called during cleanup, > then {{next( )}} should gracefully handle that case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DRILL-5083) RecordIterator can sometimes restart a query on close
[ https://issues.apache.org/jira/browse/DRILL-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Rogers updated DRILL-5083: --- Attachment: DrillOperatorErrorHandlingRedesign.pdf Proposed design to address the issue at a fundamental level. > RecordIterator can sometimes restart a query on close > - > > Key: DRILL-5083 > URL: https://issues.apache.org/jira/browse/DRILL-5083 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Paul Rogers >Priority: Minor > Attachments: DrillOperatorErrorHandlingRedesign.pdf > > > This one is very confusing... > In a test with a MergeJoin and external sort, operators are stacked something > like this: > {code} > Screen > - MergeJoin > - - External Sort > ... > {code} > Using the injector to force a OOM in spill, the external sort threw a > UserException up the stack. This was handed by: > {code} > IteratorValidatorBatchIterator.next( ) > RecordIterator.clearInflightBatches( ) > RecordIterator.close( ) > MergeJoinBatch.close( ) > {code} > Which does the following: > {code} > // Check whether next() should even have been called in current state. > if (null != exceptionState) { > throw new IllegalStateException( > {code} > But, the exceptionState is set, so we end up throwing an > IllegalStateException during cleanup. > Seems the code should agree: if {{next( )}} will be called during cleanup, > then {{next( )}} should gracefully handle that case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (DRILL-5083) RecordIterator can sometimes restart a query on close
[ https://issues.apache.org/jira/browse/DRILL-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Rogers updated DRILL-5083: --- Summary: RecordIterator can sometimes restart a query on close (was: IteratorValidator does not handle RecordIterator cleanup call to next( )) > RecordIterator can sometimes restart a query on close > - > > Key: DRILL-5083 > URL: https://issues.apache.org/jira/browse/DRILL-5083 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Paul Rogers >Priority: Minor > > This one is very confusing... > In a test with a MergeJoin and external sort, operators are stacked something > like this: > {code} > Screen > - MergeJoin > - - External Sort > ... > {code} > Using the injector to force a OOM in spill, the external sort threw a > UserException up the stack. This was handed by: > {code} > IteratorValidatorBatchIterator.next( ) > RecordIterator.clearInflightBatches( ) > RecordIterator.close( ) > MergeJoinBatch.close( ) > {code} > Which does the following: > {code} > // Check whether next() should even have been called in current state. > if (null != exceptionState) { > throw new IllegalStateException( > {code} > But, the exceptionState is set, so we end up throwing an > IllegalStateException during cleanup. > Seems the code should agree: if {{next( )}} will be called during cleanup, > then {{next( )}} should gracefully handle that case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)