Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/778#discussion_r105522650
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/xsort/managed/PriorityQueueCopierTemplate.java
---
@@ -57,9 +57,12 @@ public void setup(FragmentContext context,
BufferAllocator allocator, VectorAcce
queueSize = 0;
for (int i = 0; i < size; i++) {
- vector4.set(i, i, batchGroups.get(i).getNextIndex());
- siftUp();
- queueSize++;
+ int index = batchGroups.get(i).getNextIndex();
+ vector4.set(i, i, index);
--- End diff --
This is tricky, and likely to due conflicting design decisions.
It seems that the vector container retrieved by `get()` has a built-in
iterator. Not a good design as it will cause havoc if two bits of code try to
iterate at the same time. Sigh...
The iterator decides to return -1 when it reaches the end. That is OK, as
long as code checks.
The original code did not check, it just used -1 (truncated to 16 bits,
stored as a char, so 65535) as a row index.
The solution is to not add the batch to the "queue" when the iterator
returns -1 in the first position.
Note that if the iterator has simply returned the count at the end, and we
used the classic "index >= count" as the terminal condition, then none of this
would be necessary.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
