If you search the trunk for "pool" you will find 24 instances - some in
seed and demo data, and a few in code. So clearly, those things will not
work if you rename the pool.
The feature remains in place because there are legitimate reasons to
have different pools - but they are mostly edge cases.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 12/29/2013 1:06 PM, Rupert Howell wrote:
I've used this configuration renaming pools many times and it's always
worked fine for me.
What's the point of this being able to be set in a configuration file
if it shouldn't be changed? Might as well get rid of it.
Rupert Howell
Provolve Ltd.
Technopole
Kingston Crescent
Portsmouth
PO2 8FA
07909 685308
http://www.provolve.com
On 29 Dec 2013, at 13:37, Adrian Crum <[email protected]>
wrote:
One more thing - I noticed you are renaming the job pools. That is a bad idea. I've noticed some
code has the "pool" job pool hard-coded, and the seed/demo data expects there to be a
"pool" job pool. (Renaming pools is conceptually correct, but not all developers have
followed that design pattern.) So, there is a chance some things won't work when you rename the
pools.
So, to implement what you described, just leave everything as-is and only change the
poll-enabled="true" setting as I mentioned before.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 12/29/2013 8:28 AM, Adrian Crum wrote:
No, that is not correct. Set poll-enabled="true" only on the server that
will be servicing the jobs, all others should be set to "false".
The schema contains documentation on how to set up the Job Scheduler. If
there is missing information, or if the information is not clear, then
please let me know and I will update it.
Also be aware that each sever must have a unique name - specified in the
unique.instanceId property in general.properties.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 12/29/2013 8:16 AM, Rupert Howell wrote:
Pierre. This is correct.
All front end initiated asynchronous services will be executed by the
backend server and the backend server will run its own in this
configuration.
Rupert Howell
Provolve Ltd.
Technopole
Kingston Crescent
Portsmouth
PO2 8FA
07909 685308
http://www.provolve.com
On 29 Dec 2013, at 13:01, Pierre Smits <[email protected]> wrote:
Hi Rupert,
Thanks for the info.
So to understand the setting in serviceengine.xml correctly I would have
the following on the backend spoke:
<thread-pool send-to-pool="*BackEndPool01*>"
purge-job-days="4"
failed-retry-min="3"
ttl="120000"
jobs="100"
min-threads="2"
max-threads="5"
poll-enabled="true"
poll-db-millis="30000">
<run-from-pool name="*BackEndPool01*"/>
</thread-pool>
And on the frontend spoke I would have:
<thread-pool send-to-pool="*BackEndPool01*"
purge-job-days="4"
failed-retry-min="3"
ttl="120000"
jobs="100"
min-threads="2"
max-threads="5"
poll-enabled="true"
poll-db-millis="30000">
<run-from-pool name="*FrontEndPool01*"/>
</thread-pool>
And set the services on any spoke to point to where I want to have it
executed, eg:
<JobSandbox jobId="8200" jobName="Clear EntitySyncRemove Info"
runTime="2000-01-01
00:00:00.000" serviceName="cleanSyncRemoveInfo" poolId="*BackEndPool01*"
runAsUser="system" tempExprId="MIDNIGHT_DAILY" maxRecurrenceCount="-1"/>
Is this assumed correctly?
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
