| Job.schedule( ) performance problem [message #333425] |
Wed, 10 December 2008 12:32  |
Eclipse User |
|
|
|
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.
|
|
|
| Re: Job.schedule( ) performance problem [message #333450 is a reply to message #333425] |
Thu, 11 December 2008 12:02  |
| Eclipse User |
|
|
|
Such analysis is definitely of interest, but the platform mail list or
bugzilla entry is more appropriate.
Randall Theobald wrote:
> 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.
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02852 seconds
Home