Resource Cluster Aware Scheduler Introduction #182
Conversation
sundargates
requested review from
codyrioux,
nickmahilani,
jeffchao,
piygoyal,
calvin681,
Andyz26,
hmitnflx,
markcho and
liuml07
as code owners
| /** | ||
| * Factory for the Mantis Scheduler based on the JobDefinition | ||
| */ | ||
| public interface MantisSchedulerFactory { |
There was a problem hiding this comment.
Shall we keep interface naming with prefix "I"?
There was a problem hiding this comment.
I'm not too fond of that convention, honestly. I don't mind following it if it's consistently followed. However, from whatever I can see from the current Mantis code, I don't think a lot of components follow that style.
sundargates
changed the title
| } | ||
|
|
||
| @Override | ||
| public Receive createReceive() { |
There was a problem hiding this comment.
what about when the scheduler is not master? should it stop scheduling requests etc..?
There was a problem hiding this comment.
if the scheduler is not master, then the default ServiceLifecycle shuts down the master and waits for it to get restarted.
| TaskExecutorGateway gateway = | ||
| resourceCluster.getTaskExecutorGateway(event.getTaskExecutorID()).join(); | ||
|
|
||
| TaskExecutorRegistration info = | ||
| resourceCluster.getTaskExecutorInfo(event.getTaskExecutorID()).join(); |
There was a problem hiding this comment.
Are the two 'get' calls here involve any long IO ops for blocking concern?
There was a problem hiding this comment.
No, these should be pretty cheap. The only reason they get async responses is because they send fire-and-forget messages to the actors involved.
Context
This diff introduces a new scheduler based on resource cluster fundamentals.
Checklist
./gradlew buildcompiles code correctly./gradlew testpasses all testsCONTRIBUTING.md