I am a performance analyst for an adopting product and am analyzing high
intermittent lock contention. One source of the contention appears to be
from jobs scheduling themselves with a high frequency (which leads to the
JobManager obtaining its global lock every time).
It seems that most of the calls to schedule() could be basically free if
the schedule method only actually made the call to the JobManager if the
job's getState method returns Job.NONE or Job.RUNNING.
I know that the Job.getState method's javadoc declares it to be inherently
volatile, however, if the job's state was SLEEPING or WAITING "recently"
(meaning when the return value was set, so it was definitely in this state
after the client's request to schedule) we know that scheduling is
pointless since the JobManager does nothing.
Does anyone see any problem with this approach? It would solve a lot of
the strain on the Jobs locking. If not, I will go ahead and open a
bugzilla for the issue.