Adrian, Rupert,
The renamed job pool was only an example. I haven't renamed any job in the
setup as I understood that there might be predicaments with dependencies in
a running environment.
Based on the feedback given by both of you, I came up with following
configuration:
On any front end (user oriented) server I keep the settings regarding the
original thread-pool as-is, but set the poll-enabled attribute to 'false'.
On any back end server I also keep the settings regarding the thread-pool
as-is.
This will ensure that existing (in seed, seed-initial and hardcoded) job
definition keeps working as-is.
Additionally I create on the (new) front end server a new thread-pool like
this:
<thread-pool send-to-pool="pool"
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="FrontEnd01pool"/>
</thread-pool>
This will enable us to be flexible with regards to where new jobs (not from
seed, seed-initial and hardcoded) are initiated and where they are
executed. Or am I mistaken?
With regards to those with pool hardcoded, is it correctable or is it
required?
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sun, Dec 29, 2013 at 2:36 PM, 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
>>>
>>>
