You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by GitBox <gi...@apache.org> on 2021/01/27 07:07:17 UTC
[GitHub] [phoenix] stoty opened a new pull request #1114: PHOENIX-6342 RoundRobinResultIterator doesn't close itself when resul…
stoty opened a new pull request #1114:
URL: https://github.com/apache/phoenix/pull/1114
…t size = fetchsize-1
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [phoenix] stoty commented on a change in pull request #1114: PHOENIX-6342 RoundRobinResultIterator doesn't close itself when resul…
Posted by GitBox <gi...@apache.org>.
stoty commented on a change in pull request #1114:
URL: https://github.com/apache/phoenix/pull/1114#discussion_r565101726
##########
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?
Yes. When all iterators set numScannersCacheExhausted , and we're at the end, getIterators() will return and empty collection, as close() is skipped.
> 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 is the pattern everywhere in the code. This is also less error-prone, and encapsulates the logic within the class, I see no reason to change this, either.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [phoenix] virajjasani commented on a change in pull request #1114: PHOENIX-6342 RoundRobinResultIterator doesn't close itself when resul…
Posted by GitBox <gi...@apache.org>.
virajjasani commented on a change in pull request #1114:
URL: https://github.com/apache/phoenix/pull/1114#discussion_r565095342
##########
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:
It seems we already do have practice of closing iterators when next() exhausts all rows e.g `ConcatResultIterator`, `LimitingResultIterator`. I think we are good here.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [phoenix] stoty commented on a change in pull request #1114: PHOENIX-6342 RoundRobinResultIterator doesn't close itself when resul…
Posted by GitBox <gi...@apache.org>.
stoty commented on a change in pull request #1114:
URL: https://github.com/apache/phoenix/pull/1114#discussion_r565101726
##########
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?
Yes. When all iterators set numScannersCacheExhausted , and we're at the end, getIterators() will return an empty collection, as close() is skipped.
> 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 is the pattern everywhere in the code. This is also less error-prone, and encapsulates the logic within the class, I see no reason to change this, either.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [phoenix] stoty closed pull request #1114: PHOENIX-6342 RoundRobinResultIterator doesn't close itself when resul…
Posted by GitBox <gi...@apache.org>.
stoty closed pull request #1114:
URL: https://github.com/apache/phoenix/pull/1114
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [phoenix] stoty commented on pull request #1114: PHOENIX-6342 RoundRobinResultIterator doesn't close itself when resul…
Posted by GitBox <gi...@apache.org>.
stoty commented on pull request #1114:
URL: https://github.com/apache/phoenix/pull/1114#issuecomment-768168300
:broken_heart: **-1 overall**
| Vote | Subsystem | Runtime | Comment |
|:----:|----------:|--------:|:--------|
| +0 :ok: | reexec | 0m 34s | Docker mode activated. |
||| _ Prechecks _ |
| +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. |
| +1 :green_heart: | hbaseanti | 0m 0s | Patch does not have any anti-patterns. |
| +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. |
| -1 :x: | test4tests | 0m 0s | The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. |
||| _ master Compile Tests _ |
| +1 :green_heart: | mvninstall | 15m 51s | master passed |
| +0 | hbaserecompile | 22m 16s | HBase recompiled. |
| +1 :green_heart: | compile | 1m 3s | master passed |
| +1 :green_heart: | checkstyle | 0m 34s | master passed |
| +1 :green_heart: | javadoc | 0m 51s | master passed |
| +0 :ok: | spotbugs | 3m 2s | phoenix-core in master has 955 extant spotbugs warnings. |
||| _ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 8m 21s | the patch passed |
| +0 | hbaserecompile | 17m 47s | HBase recompiled. |
| +1 :green_heart: | compile | 1m 5s | the patch passed |
| +1 :green_heart: | javac | 1m 5s | the patch passed |
| +1 :green_heart: | checkstyle | 0m 35s | the patch passed |
| +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. |
| +1 :green_heart: | javadoc | 0m 51s | the patch passed |
| +1 :green_heart: | spotbugs | 3m 9s | the patch passed |
||| _ Other Tests _ |
| -1 :x: | unit | 111m 12s | phoenix-core in the patch failed. |
| +1 :green_heart: | asflicense | 0m 44s | The patch does not generate ASF License warnings. |
| | | 163m 55s | |
| Reason | Tests |
|-------:|:------|
| Failed junit tests | phoenix.end2end.PermissionNSEnabledIT |
| | phoenix.end2end.PermissionsCacheIT |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1114/1/artifact/yetus-general-check/output/Dockerfile |
| GITHUB PR | https://github.com/apache/phoenix/pull/1114 |
| Optional Tests | dupname asflicense javac javadoc unit spotbugs hbaserebuild hbaseanti checkstyle compile |
| uname | Linux 9ea94fa310ed 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev/phoenix-personality.sh |
| git revision | master / ba47233 |
| Default Java | Private Build-1.8.0_242-8u242-b08-0ubuntu3~16.04-b08 |
| unit | https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1114/1/artifact/yetus-general-check/output/patch-unit-phoenix-core.txt |
| Test Results | https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1114/1/testReport/ |
| Max. process+thread count | 12456 (vs. ulimit of 30000) |
| modules | C: phoenix-core U: phoenix-core |
| Console output | https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1114/1/console |
| versions | git=2.7.4 maven=3.3.9 spotbugs=4.1.3 |
| Powered by | Apache Yetus 0.12.0 https://yetus.apache.org |
This message was automatically generated.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [phoenix] virajjasani commented on a change in pull request #1114: PHOENIX-6342 RoundRobinResultIterator doesn't close itself when resul…
Posted by GitBox <gi...@apache.org>.
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:
users@infra.apache.org
[GitHub] [phoenix] stoty commented on a change in pull request #1114: PHOENIX-6342 RoundRobinResultIterator doesn't close itself when resul…
Posted by GitBox <gi...@apache.org>.
stoty commented on a change in pull request #1114:
URL: https://github.com/apache/phoenix/pull/1114#discussion_r565101726
##########
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?
Yes. When all iterators set numScannersCacheExhausted , and we're at the end, getIterators() will return an empty collection, and close() is skipped.
> 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 is the pattern everywhere in the code. This is also less error-prone, and encapsulates the logic within the class, I see no reason to change this, either.
----------------------------------------------------------------
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:
users@infra.apache.org