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