We have in our multi-tenant setup several servers configured for HAFO
provisioning to ensure the best user experience. For this we have grouped servers as either front end or back end. The users access servers in the front-end group. We want to have the scheduled and other non user-triggered jobs and services to run on the servers that are in the back-end group. The question is how do we configure jobs and/or services to run on a specific (back-end) spoke in the setup? Or even on multiple servers (in the back-end) for failover? I appreciate your insights in this matter. Regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
Hi Pierre.
Configuration can be set in serviceengine.xml Send to pool and run from pool control which aysyncronous services are run from which server Best Regards, Rupert Howell Provolve Ltd. Technopole Kingston Crescent Portsmouth PO2 8FA 07909 685308 http://www.provolve.com > On 29 Dec 2013, at 11:05, Pierre Smits <[hidden email]> wrote: > > We have in our multi-tenant setup several servers configured for HAFO > provisioning to ensure the best user experience. For this we have grouped > servers as either front end or back end. The users access servers in the > front-end group. We want to have the scheduled and other non user-triggered > jobs and services to run on the servers that are in the back-end group. > > The question is how do we configure jobs and/or services to run on a > specific (back-end) spoke in the setup? Or even on multiple servers (in > the back-end) for failover? > > I appreciate your insights in this matter. > > Regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com |
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 |
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 <[hidden email]> 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 |
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 <[hidden email]> 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 > |
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 <[hidden email]> 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 >> |
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 <[hidden email]> 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 <[hidden email]> 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 >>> |
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 <[hidden email]> 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 <[hidden email]> 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 >>>> |
In reply to this post by Adrian Crum-3
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 < [hidden email]> 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 <[hidden email]> 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 >>> >>> |
Inline...
Adrian Crum Sandglass Software www.sandglass-software.com On 12/29/2013 5:11 PM, Pierre Smits wrote: > 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" ^^^Indicates jobs originating on this server will be sent to the job pool called "pool". > > purge-job-days="4" > > failed-retry-min="3" > > ttl="120000" > > jobs="100" > > min-threads="2" > > max-threads="5" > > poll-enabled="true" ^^^Indicates this server will poll (query) the database for new jobs to run. > > poll-db-millis="30000"> > > <run-from-pool name="FrontEnd01pool"/> ^^^Indicates this server will run jobs sent to the "FrontEnd01pool" pool. Jobs sent to the pool named "pool" will need to be run on a different server. > > </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? The hard-coded pool name should be replaced with code that gets the send-to-pool setting from the service engine. I don't see how we can "fix" the seed/demo data issue - the included data must make some assumptions about the default setup. > 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 < > [hidden email]> 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 <[hidden email]> 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 >>>> >>>> > |
Hi Adrian, Rupert,
Thanks for the patience and elaborative explanation(s). I agree that hard-coded pool names should be replaced. As for the seed and demo data, these needn't be fixed as they run on defined pools. That a multi server setup requires more configuration than a single server should be known . Regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
Administrator
|
Hi Pierre,
You might provide information in the wiki page https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support Jacques On Monday, December 30, 2013 9:53 AM [hidden email] wrote > Hi Adrian, Rupert, > > Thanks for the patience and elaborative explanation(s). > > I agree that hard-coded pool names should be replaced. As for the seed and > demo data, these needn't be fixed as they run on defined pools. That a > multi server setup requires more configuration than a single server should > be known . > > Regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com |
Jacques,
This might prove to be more multi-server oriented than multi-tenant. I have taken a quick look around in the OFBiz wiki pages, but couldn't find a placeholder that easily. 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, Jan 5, 2014 at 11:22 AM, Jacques Le Roux < [hidden email]> wrote: > Hi Pierre, > > You might provide information in the wiki page > https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support > > Jacques > > On Monday, December 30, 2013 9:53 AM [hidden email] wrote > > Hi Adrian, Rupert, > > > > Thanks for the patience and elaborative explanation(s). > > > > I agree that hard-coded pool names should be replaced. As for the seed > and > > demo data, these needn't be fixed as they run on defined pools. That a > > multi server setup requires more configuration than a single server > should > > be known . > > > > Regards, > > > > Pierre Smits > > > > *ORRTIZ.COM <http://www.orrtiz.com>* > > Services & Solutions for Cloud- > > Based Manufacturing, Professional > > Services and Retail & Trade > > http://www.orrtiz.com > |
Most likely the best place for it is in the Production Setup Guide.
Adrian Crum Sandglass Software www.sandglass-software.com On 1/5/2014 8:27 AM, Pierre Smits wrote: > Jacques, > > This might prove to be more multi-server oriented than multi-tenant. I have > taken a quick look around in the OFBiz wiki pages, but couldn't find a > placeholder that easily. > > 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, Jan 5, 2014 at 11:22 AM, Jacques Le Roux < > [hidden email]> wrote: > >> Hi Pierre, >> >> You might provide information in the wiki page >> https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support >> >> Jacques >> >> On Monday, December 30, 2013 9:53 AM [hidden email] wrote >>> Hi Adrian, Rupert, >>> >>> Thanks for the patience and elaborative explanation(s). >>> >>> I agree that hard-coded pool names should be replaced. As for the seed >> and >>> demo data, these needn't be fixed as they run on defined pools. That a >>> multi server setup requires more configuration than a single server >> should >>> be known . >>> >>> Regards, >>> >>> Pierre Smits >>> >>> *ORRTIZ.COM <http://www.orrtiz.com>* >>> Services & Solutions for Cloud- >>> Based Manufacturing, Professional >>> Services and Retail & Trade >>> http://www.orrtiz.com >> > |
Ok. I created a jira as a reminder.
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, Jan 5, 2014 at 2:47 PM, Adrian Crum < [hidden email]> wrote: > Most likely the best place for it is in the Production Setup Guide. > > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/5/2014 8:27 AM, Pierre Smits wrote: > >> Jacques, >> >> This might prove to be more multi-server oriented than multi-tenant. I >> have >> taken a quick look around in the OFBiz wiki pages, but couldn't find a >> placeholder that easily. >> >> 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, Jan 5, 2014 at 11:22 AM, Jacques Le Roux < >> [hidden email]> wrote: >> >> Hi Pierre, >>> >>> You might provide information in the wiki page >>> https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support >>> >>> Jacques >>> >>> On Monday, December 30, 2013 9:53 AM [hidden email] wrote >>> >>>> Hi Adrian, Rupert, >>>> >>>> Thanks for the patience and elaborative explanation(s). >>>> >>>> I agree that hard-coded pool names should be replaced. As for the seed >>>> >>> and >>> >>>> demo data, these needn't be fixed as they run on defined pools. That a >>>> multi server setup requires more configuration than a single server >>>> >>> should >>> >>>> be known . >>>> >>>> Regards, >>>> >>>> Pierre Smits >>>> >>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>> Services & Solutions for Cloud- >>>> Based Manufacturing, Professional >>>> Services and Retail & Trade >>>> http://www.orrtiz.com >>>> >>> >>> >> |
Free forum by Nabble | Edit this page |