[
https://issues.apache.org/jira/browse/TAJO-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019602#comment-14019602
]
ASF GitHub Bot commented on TAJO-839:
-------------------------------------
Github user jihoonson commented on a diff in the pull request:
https://github.com/apache/tajo/pull/17#discussion_r13477302
--- Diff:
tajo-core/src/main/java/org/apache/tajo/master/DefaultTaskScheduler.java ---
@@ -821,7 +820,7 @@ public void
assignToLeafTasks(LinkedList<TaskRequestEvent> taskRequests) {
host, container.getTaskPort()));
assignedRequest.add(attemptId);
- scheduledObjectNum -= task.getAllFragments().size();
--- End diff --
@hyunsik thanks for your comment.
I think that this will be ok because scheduledObjectNum is individually
maintained in DefaultTaskScheduler and LazyTaskScheduler. As you know, SubQuery
checks only the remaining scheduledObjects from TaskScheduler whether it is the
DefaultTaskScheduler or LazyTaskScheduler.
However, LazyTaskScheduler seems not to work as you said. As you already
know, LazyTaskScheduler has a fundamentally different architecture with that of
DefaultTaskScheduler. If we decide to maintain LazyTaskScheduler, I think that
we need to refactor the scheduler architecture to work both schedulers well.
In my opinion, we need to test the effectiveness of LazyTaskScheduler for
our decision.
I think that the representative use case of LazyTaskScheduler will be the
ETL. So, how about conducting some tests for it? If other guys agree, I'll
start.
> If all tables participate in the BROADCAST JOIN, there is some missing data.
> ----------------------------------------------------------------------------
>
> Key: TAJO-839
> URL: https://issues.apache.org/jira/browse/TAJO-839
> Project: Tajo
> Issue Type: Bug
> Reporter: Hyoungjun Kim
> Assignee: Hyoungjun Kim
> Priority: Minor
>
> See title.
> If all tables participate in the BROADCAST JOIN and table has several files,
> there is some missing data.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
