6 Replies Latest reply on Nov 4, 2010 12:27 PM by Bill Robinson

    Multiple Job servers - dispatching jobs

    Mike Reider

      Hi all, I have an architectural question,


      we have 3 physicall BL application servers setup, each one has 3 Job server instances (server profiles, TYPE=JOB) , for a total of 9 Job servers. My understanding is that all 3 app servers are aware of each other through a common DB connection. So lets say there are 100 scheduled deploy jobs that are run simultaneously,


      how does BL determine how to dispatch these jobs to the 9 Job servers? What is the mechanism that acts as this dispatcher? Does each app server know what the other app server is processing?


      I'm trying to understand where this dispatching process is running from and how it works. The client is concerned that running 9 Job servers with that many TCP connections to SQL will cause database latency due to round-robin dispatching of these 100 deploy jobs. Thanks.

        • 1. Re: Multiple Job servers - dispatching jobs
          Bill Robinson

          what os and arch are you running your appservers?  also, how many config instances do you have? (just wondering)


          basically, a job server will pickup a job that's queued in the db.  it will start using up work item threads (default is 50 per instance) to do whatever the job does then, once it runs out on one instance it will start sending WITs to other appservers.  each appserver can handle some number of remoteworkitem threads.


          picking up the job from the db is first-come/first-serve and the appservers are constantly polling the db for jobs to run.

          • 2. Re: Multiple Job servers - dispatching jobs
            Mike Reider

            Hi Bill, thanks for the quick reply,


            the environment is BL v 8.0,


            3 physical app servers, Win2003 Enterprise 32bit, SQL 2005


            we have 2 servers setup as Config (with 3 additional Job server profiles), the 3rd server is Job only (3 Job profiles/instances). The reason for 2 servers having config is redundancy, we will have a load balancer running between these 2 servers for user BL console logins. .


            so let me get this straight, lets say my 3 app servers A,B,C get 100 deploy jobs to process. Server A scans the DB for outstanding jobs and picks up jobs and starts processing worker threads, once its 1st Job profile/instance is maxed out(memory), it sends the rest to 2nd instance, and then 3rd Job instance.


            Once all 3 Job instances are maxed out, A will then offload its remaining threads to server B?


            how does it communicate to B directly, or is it all done through the DB. Does A update the DB with its remaining threads, then server B scans the DB and sees these offloaded threads, and picks them up for processing? Is there any direct communication between the 3 servers? Thanks!

            • 3. Re: Multiple Job servers - dispatching jobs

              Consider each job instance a separate server for this purpose. Each job server instance polls the db for jobs. It uses its 50 wits and then any other instance can take the remaining.

              1 of 1 people found this helpful
              • 4. Re: Multiple Job servers - dispatching jobs
                Mike Reider

                Bill, Adam thanks for the answer, this clears it up. I was thinking that the app servers talk to each other directly, but all 'communication' is done through DB reads. Thanks. 

                • 5. Re: Multiple Job servers - dispatching jobs

                  You got it. That is what helps keep our solution "stateless".

                  • 6. Re: Multiple Job servers - dispatching jobs
                    Bill Robinson

                    actually, the appservers do talk to each other - to figure out what appserver to offload work items to, and the appserver that picked up the job (which could be random in your example, it's unlikely that all jobs would be picked up by 1 job server) controls the job (handing out the work items) - that's not handled through the db afaik.