The ProportionalCapacityPreemptionPolicy does indeed need to access methods that are specific to the CapacityScheduler.
The three offending methods are:
- scheduler.getRootQueue(); (which is a CSQueue)
However more generally this policy only makes sense when paired with the CapacityScheduler, so it needs somehow to check that the underlying scheduler is indeed a CapacityScheduler.
This is coming up again in the work towards
YARN-1051, as we have other "monitors" interacting with the underlying scheduler, possibly in ways that are specific to one specific scheduler.
Speaking with Chris Douglas we seem to agree that the simulator would be much more useful if it allows to simulate specifics of each scheduler more than just exercise the general API (specifically I would not use it otherwise), and hacking the Scheduler API (and classes using it) to keep the abstraction in the simulator clean doesn't seem to be a solution. This seems a job for aspect programming... though it comes with its own set of headaches (see mumak).
Maybe the simulator could also hijack the creation of monitors, and pass down the actual scheduler to those (assuming the rest of your metrics are collected in methods not used by the monitor).