An Overview of Using MAX JOBS, FLOW LIMIT and ACTIVATION LIMIT For Process Configuration

Many people are unclear and confused about the difference and usage scenarios of MAX JOBS, FLOW LIMIT and ACTIVATION LIMIT while configuring processes at the time of deploying an EAR. In this tutorial, I am going to explain the difference between these parameters and will discuss their usage scenarios in detail.

Video Tutorial About Max Job, Flow Limit, Activation Limit and Thread Count

On  TutorialsPedia YouTube Channel, I have explained these concepts in Video format. If you prefer to watch it in video form, watch it below and don’t forget to subscribe the channel.


If you prefer to read further in Text format, continue reading below.

 

MAX JOB:

This parameter specified the maximum number of process instances that can concurrently be loaded into memory. For example, If you set the value of MAX JOB as 5 for a certain process in its configuration; at a time 5 process instances of this process can reside in memory as shown in the diagram below:

using max job in tibco process configuration

The value to be set for MAX JOB parameter depends on your available memory resources. The number of process instances to reside in memory should be limited keeping in mind the total memory available in order to avoid memory shortage issues in production environment.

However in situations where memory pool is quite high and there is no fear of memory shortage, you can specify value of MAX JOB as 0 (zero). In this case, unlimited numbers of process instances get loaded in the memory without any paging done.

FLOW LIMIT:

The value of FLOW LIMIT specifies the maximum number of concurrently running process instance to start before suspending the process starter for a certain process.

Once a process engine reaches to the value of FLOW LIMIT; It goes into the FLOW_CONTROLLED state in which new process instances don’t get created and only existing process instances keep on running to their completion.  Once the number of running process instances drops to the half of the value of FLOW LIMIT; process engine leaves FLOW_CONTROLLED state and process instances continue to start again.

ACTIVATION LIMIT:

Activation limit flag specifies that once a process instance is loaded in the memory; It must reside in memory till the time its execution is completed.  This flag is useful if we wish to process the incoming requests in sequential manner or if you want to enforce limited concurrent execution of process instances.

Understanding the effects of configurations of MAX JOB, FLOW LIMIT and ACTIVATION LIMIT:

Let’s take different combinations of the configuration values for MAX JOB, FLOW LIMIT and ACTIVATION LIMIT and see how processing of requests by TIBCO process engine is impacted by these values:

Scenario 1: Unlimited Process Instances can be created and Loaded

If available memory pool is very high compared to the incoming requests landing on a TIBCO server, you can specify the values of MAX JOB and FLOW LIMIT as Zero. ACTIVATION LIMIT flag becomes inapplicable in such scenario:

max job and flow limit zero value

 

Scenario 2: Limited Process Instance creation with no paging:

In the scenario shown in the diagram below, n number of process instances can be created before placing the engine in FLOW_CONTROLLED state. There is no limit on in memory placing of process instances as value of MAX JOB is set to zero:

limited process instances with no paging

Scenario 3: Only a certain number of created process instances loaded in memory:

In the scenario shown below, out of n process instances created, only 1 can be loaded in memory at a time where it resides till completion of its execution. Sequential execution is ensured by setting the activation limit flag:

n number of process instances created and m number of instances to load in memory

Ajmal Abbasi

Ajmal Hussain Abbasi is Integration Consultant By Profession with 13+ years experience in Integration domain mainly with TIBCO products. He has extensive practical knowledge of TIBCO Business Works, TIBCO Cloud, TIBCO Flogo, TIBCO Mashery, TIBCO Spotfire, EMS and TIBCO ActiveSpaces. He has worked on a number of highly critical integration projects in various sectors by using his skills in TIBCO Flogo, TIBCO API Management (Mashery), TCI, Tibco Designer, TIBCO Business Studio, Adapters, TIBCO EMS, RV, Administrator, TIBCO BE, TIBCO ActiveSpaces etc. Ajmal Abbasi has experience with MuleSoft ESB as well. Ajmal Abbasi is also experienced in the area of API Management particularly with WSO2 API management platforms. Ajmal Abbasi is also experienced in developing solutions using Core Java and J2EE Technologies. You can contact Ajmal Abbasi for Consultancy, Technical Assistance and Technical Discussions.

More Posts - Website - Facebook - LinkedIn - YouTube

20 thoughts on “An Overview of Using MAX JOBS, FLOW LIMIT and ACTIVATION LIMIT For Process Configuration

  1. Sathya

    Hi Bro,

    I need TIBCO training, could you please provide th trainging . please share the contact details

    Reply
  2. sreenivasulu

    Hi Ajaml,

    I have one query how we can add EAR file to another or 2 admin domains by using tibco admin domain ?

    Reply
  3. Pingback: Top Reasons of Poor Performance of A TIBCO BW based Project | TutorialsPedia

  4. Pingback: TIBCO BW Memory Efficient Utilization | TutorialsPedia

  5. srikanth

    Hello,

    How the max job and thread count is different? .could you explain it..

    Thanks in advance

    Reply
    1. Tilak

      Thread count is engine level property, whereas max job is component/application level property. So lets say if thread count is 8 and max job is 5, that means only 5 threads will be created for that instance rather than 8. Whereas for any other application on same engine if maxjob is 0 then 8 threads will be created at a time.

      Reply
      1. Tilak

        + In addition to same, Maxjob specify how many instances can be loaded into memory whereas thread count specify how many can be executed concurrently.

        Reply
  6. shweta

    Hi Ajmal,
    I have one query. If max jobs =5 , flow limit is n and activation limit is checked then also incoming events are processes in order.
    Can you please help me for clearing the doubt

    Reply
  7. Apurva

    If max jobs =10 , flow limit is n and activation limit is not checked then how the execution will be?

    Reply
  8. Suresh Kumar

    Hi sir,

    Could you please find my doubt I have maxjob=5 and flowlimit=10 .I have to proceed 10 msg . can I know”it is running”..

    Reply
    1. Ajmal Abbasi Post author

      In this case, 5 jobs will be running at a time but a total of 10 jobs will be created with 5 waiting in memory.

      Reply
  9. Suresh Kumar

    Hi sir,

    Could I know one doubt “max job=5 and flowlimit=10 and I have to proceed 15 msg.how it’s running..

    Reply
    1. Dhanesh

      Hi Suresh,

      In this case, 10 jobs will be created initially. 5 would start executing and next 5 would wait in the memory, with the process starter in the disabled state. Once the first 5 are finished executing then the starter will get enabled and the remaining 5 messages will get loaded into memory. The next 5 will get loaded for execution at the same time.

      Hi Ajmal, kindly confirm.

      Reply
      1. Dhanesh

        Correction :: Process starter will wait in FLOW_CONTROLLED state (Will not get disabled)

        Reply
  10. Vishnu Singh

    HI Ahmed,

    Our Production server goes down several time due to cpu utilization 100%. we had set MAX JOB and FLOW Limit to 1,1 and activitation limit is also enabled as we required sequential processing. can you please suggest if there is a way to avoid CPU utilization.

    also we check /PROC/$PID and each time the consuming process is different.

    Thanks,
    Vishnu

    Reply
  11. Pingback: 10 Tips for Tuning TIBCO BW Performance | TutorialsPedia

  12. Pingback: Tips For Tuning TIBCO BW Performance | TutorialsPedia

  13. Tejas Kavitkar

    Can we have the Max Job set in the designer. We have to connect to our servers many number of times from the designer itself. If the server has 1000s of messages, all are loaded in the designer triggering parallel starts for that process. Can that be avoided by just say having 3 messages parallely or just 1 at a time?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *