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, <[email protected]> wrote:
> Quoting Brett Palmer <[email protected]>:
>
> *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
