drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paul-rogers <...@git.apache.org>
Subject [GitHub] drill pull request #778: DRILL-5344: Priority queue copier fails with an emp...
Date Sat, 11 Mar 2017 02:17:16 GMT
Github user paul-rogers commented on a diff in the pull request:

    --- 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,
         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
    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 infrastructure@apache.org or file a JIRA ticket
with INFRA.

View raw message