Brett,
Thank you for the update. I will look into this.
-Adrian
On 9/19/2012 6:02 AM, Brett Palmer wrote:
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
