Adrian, Thanks I'll take an update and try it out.
Brett On Aug 7, 2012 4:23 PM, "Adrian Crum" <adrian.c...@sandglass-software.com> wrote: > Brett, > > I think I solved your problems with my recent commits, ending with rev > 1370566. Let me know if it helps. > > -Adrian > > On 8/5/2012 4:53 PM, Brett Palmer wrote: > >> Adrian, >> >> Thanks for the update. Here are some feedback points on your listed >> items: >> >> 1. JobPoller get out-of-memor error. We've seen this a lot in production >> servers when the JobSandbox table is not constantly pruned of old records. >> It would be nice if the poller restricted its search for only active >> records it could process. >> >> 2. Queue for capturing missing records would be good. From item 1 above >> we >> have had locks on table when the poller is busy doing a scan and new jobs >> cannot be added or time out. >> >> Other wish items: >> >> - Ability to assign different service engines to process specific job >> types. We often multiple application servers but want to limit how many >> concurrent jobs are run. For example, if I had 4 app servers connected to >> the same DB I may only want one app server to service particular jobs. I >> thought this feature was possible but when I tried to implement it by >> changing some of the configuration files it never worked correctly. >> >> - JMS support for the service engine. It would be nice if there was a JMS >> interface for those that want to use JMS as their queuing mechanism for >> jobs. >> >> >> Brett >> >> On Sun, Aug 5, 2012 at 6:21 AM, Adrian Crum < >> adrian.crum@sandglass-**software.com <adrian.c...@sandglass-software.com>> >> wrote: >> >> 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 >>> >>> >>> >>> >
