On 8/5/2012 11:02 AM, Adrian Crum wrote:
I just committed a bunch of changes to the Job Manager group of
classes. The changes help simplify the code and hopefully make the Job
Manager more robust. On the other hand, I might have broken something.
;) I will monitor the mailing list for problems.
I believe the JobPoller settings in serviceengine.xml (the
<thread-pool> element) should be changed. I think min-threads should
be set to "2" and max-threads should be set to "5". Creating lots of
threads can hurt throughput because the JVM spends more time managing
them. I would be interested in hearing what others think.
Thinking about this more, there are some other things that need to be fixed:
1. The JobPoller uses an unbounded queue. In a busy server, there is the
potential the queue will grow in size until it causes an out-of-memory
condition.
2. There is no accommodation for when a job cannot be added to the queue
- it is just lost. We could add a dequeue method to the Job interface
that will allow implementations to recover or reschedule the job when it
can't be added to the queue.
3. There is a JobPoller instance per delegator, and each instance
contains the number of threads configured in serviceengine.xml. With the
current max-threads setting of 15, a multi-tenant installation with 100
tenants will create up to 1500 threads. (!!!) A smarter strategy might
be to have a single JobPoller instance that services multiple JobManagers.
-Adrian
