[
https://issues.apache.org/jira/browse/FLINK-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15437459#comment-15437459
]
Stephan Ewen commented on FLINK-4459:
-------------------------------------
Yes, this is needed.
In the master branch, the current {{Scheduler}} should implement the
{{SlotProvider}} interface. It would basically only hand out futures or slots,
and then the {{ExecutionGraph}} code could check that the futures are always
already completed.
In the FLIP-6 branch, we can adapt the scheduler to a different
{{SlotProvider}}. I think it makes sense there as well to keep the logic about
{{SlotSharingGroup}} and {{CoLocationConstraint}} out of the {{SlotPool}} and
in a separate class (called {{Slotprovider}} or {{Scheduler}} or whatever.
> Introduce SlotProvider for Scheduler
> ------------------------------------
>
> Key: FLINK-4459
> URL: https://issues.apache.org/jira/browse/FLINK-4459
> Project: Flink
> Issue Type: Improvement
> Components: Scheduler
> Reporter: Till Rohrmann
>
> Currently the {{Scheduler}} maintains a queue of available instances which it
> scans if it needs a new slot. If it finds a suitable instance (having free
> slots available) it will allocate a slot from it.
> This slot allocation logic can be factored out and be made available via a
> {{SlotProvider}} interface. The {{SlotProvider}} has methods to allocate a
> slot given a set of location preferences. Slots should be returned as
> {{Futures}}, because in the future the slot allocation might happen
> asynchronously (Flip-6).
> In the first version, the {{SlotProvider}} implementation will simply
> encapsulate the existing slot allocation logic extracted from the
> {{Scheduler}}. When a slot is requested it will return a completed or failed
> future since the allocation happens synchronously.
> The refactoring will have the advantage to simplify the {{Scheduler}} class
> and to pave the way for upcoming refactorings (Flip-6).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)