[ 
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)

Reply via email to