Adrian, I'll have to setup a load test to verify that a large number of pending jobs in the JobSandbox do not saturate the server. I'll also work with the thread counts to see what works for us.
Before I read your reply I had configured the service engine to use a "send-to-pool=poolX" but did not configure any "run-from-pool" names that matched "poolX". I then use the webtools interface to run a service. The default pool displayed was "poolX" in the form. I entered the service name and executed the service. The service ran but I didn't expect it to run because there wasn't a "send-to-pool" with a matching name. This functionality seems to disagree with what you said about "If you don't have a <run-from-pool name="pool"/> element somewhere, then jobs sent to the "pool" pool will not be serviced.", but maybe I am missing something. <thread-pool send-to-pool="poolX" purge-job-days="4" failed-retry-min="3" ttl="120000" jobs="100" min-threads="2" max-threads="5" wait-millis="1000" poll-enabled="true" poll-db-millis="30000"> <run-from-pool name="pool"/> <run-from-pool name="testPool"/> <run-from-pool name="pool2"/> <run-from-pool name="pool3"/> <run-from-pool name="pool4"/> </thread-pool> I'll post the results of my load test as soon as it is completed. Brett On Tue, Sep 18, 2012 at 2:38 AM, <adrian.c...@sandglass-software.com> wrote: > Quoting Brett Palmer <brettgpal...@gmail.com>: > > *Adrian, >> >> >> I ported our code over to the newest ofbiz trunk and tried out the changes >> for the new service engine. The changes that you made are working very >> well. I configured our server to use multiple pools and then scheduled >> various jobs to those pools. Servers that were not configured to service >> the pools left the jobs dormant and servers that were configured to >> service >> the new pools did so as expected. >> > > To be clear, that has always been the behavior of the Job Scheduler. I did > not change that. > > > >> These new changes will work for us in our production environment. Thanks >> for implementing them. I now need to work on tuning the configuration >> settings based on the particular jobs and the capacity of our servers. >> > > The changes were intended to prevent the Job Scheduler from saturating the > server under heavy load. So, those are the results I would be interested in > hearing about. > > > >> I did have another question on the thread-pool configuration. Here is a >> sample configuration that I was using to do some of the testing. >> >> <thread-pool send-to-pool="pool" >> purge-job-days="4" >> failed-retry-min="3" >> ttl="120000" >> jobs="100" >> min-threads="2" >> max-threads="5" >> wait-millis="1000" >> poll-enabled="true" >> poll-db-millis="30000"> >> <run-from-pool name="pool"/> >> <run-from-pool name="testPool"/> >> <run-from-pool name="pool2"/> >> <run-from-pool name="pool3"/> >> <run-from-pool name="pool4"/> >> </thread-pool> >> >> Is the “send-to-pool” attribute the default pool that is used by the >> service engine for any sync and async requests through the service engine >> API? >> > > Correct. > > > >> Is there a relationship between the “send-to-pool” attribute and the >> “run-from-pool” names or are they independent of each other? For example, >> if I don't have a run-from-pool element with a name="pool" will the >> default >> "pool" still work? >> > > They are not related. If you don't have a > > <run-from-pool name="pool"/> > > element somewhere, then jobs sent to the "pool" pool will not be serviced. > > >> Thanks again for you work on the service engine. We really appreciate it. >> >> Let me know if you need more feedback on the new changes. >> >> >> >> Brett* >> >> >> snip