Tibco Administrator-best practices

Consider these settings for a process with a starter actvity, say a JMS receiver:

Flow limit =100

Max jobs =25

There are 200 messages on the receiving queue before the process starts.

Once the process starts then what could be the statistics?

1)

Jobs in memory :25

Jobs paged to disk :100

Messages waiting on the queue :75

or

2)

Jobs in memory :25

Jobs paged to disk :75

Messages waiting on the queue :100

……………………………………………

Thread Count is the number of BW worker threads, each of which is entitled to run a job that is scheduled for execution, i.e. in the run-queue. Just because you have the thread does not mean it actually runs as that depends on the OS scheduling which also depends on the actually number of available hardware threads (cores plus hyper-threading) and on the state of the process (it could be blocked on IO for example). So strictly speaking even the BW worker threads only run virually concurrently - how many run physcial concurrently is a matter of HW and statements.

Max Jobs is number of jobs that can be in-memory and that are also entitled to run. So they may not run physical' at the same time as not all of them can have a BW worker thread in your example but they run logical concurrently as BW has its own scheduling which will result in jobs having to give up the BW worker thread when they reach an asynchronous activity or they executed to many steps in sequence. In that it is not much different than the OS scheduling of threads on the processors.

All of the above is also detailed in the BW documetation - there is a whole chapter on that - but sure it is one of the more difficult subjects.

For the JMS receiver also the acknowledgment mode comes into play. For CLIENT ACK the number of session determines how many jobs can be created concurrently (defined from start to confirm activity which most times is at the end anyway). This mean you do not have to set maxJobs or flowLimit. Now let's say you use EXPLICIT ACK then the maxJobs and flowLimit are again important as only way to define concurrency and thus memory footprint and other resoruce consumption. In this case flowLimit=100 will suspend the BW process starter once 100 jobs are created but not yet terminated. It will resume the job creation only once 1/2(=50) jobs run to their end. The maxJobs of 25 does result in 75 of those 100 jobs to be paged to disk - which is not really a good idea (page out and page in cost) unless you have large jobs and they are so long running that they all must be started. That is for activationLimit equals false.

With Activation Limit equals true BW would have stopped to create jobs once it reached maxJobs = 25 and thus only 25 would be in memory at any time and the higher flowLimit would be meaningless