[ 
https://issues.apache.org/jira/browse/PHOENIX-6342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272638#comment-17272638
 ] 

ASF GitHub Bot commented on PHOENIX-6342:
-----------------------------------------

virajjasani commented on a change in pull request #1114:
URL: https://github.com/apache/phoenix/pull/1114#discussion_r565092144



##########
File path: 
phoenix-core/src/main/java/org/apache/phoenix/iterate/RoundRobinResultIterator.java
##########
@@ -114,6 +114,7 @@ public Tuple next() throws SQLException {
                 index = (index + 1) % size;
             }
         }
+        close();

Review comment:
       When RRIterator#peek() (next result) is null, we close the iterator. But 
if we don't get any next result after looping through all RRIterators, we 
should close() here, that's the plan right? 
   Although this looks good, curious if caller can implement the logic of 
calling RRResultIterator#close() if RRResultIterator#next() returns null. But 
if caller logic turns out to be more complicated, sure we should go this route 
I believe.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


> RoundRobinResultIterator doesn't close itself when result size = fetchsize-1
> ----------------------------------------------------------------------------
>
>                 Key: PHOENIX-6342
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6342
>             Project: Phoenix
>          Issue Type: Sub-task
>          Components: core
>    Affects Versions: 4.15.0, 5.1.0
>            Reporter: Istvan Toth
>            Assignee: Istvan Toth
>            Priority: Blocker
>
> RoundRobinResultIterator is mising a close() method call when the last record 
> read causes the final increment to numScannersCacheExhausted.
> Most of the time this isn't fatal, as the next next() call will close the 
> scanners, and call close(), but in some hard to reproduce cases, the 
> iterators will reset, and keep sending their results again and again in an 
> infinite loop.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to