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.
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!
1 of 1 people found this helpful
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.
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.
You got it. That is what helps keep our solution "stateless".
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.