The Flow Service's Execution Model

The common thread running model named "ASFramework" is used in the service. There are thread pools in the ASFramework, so the request's multiple processing can be realized by using the FIFO (First Input First Output) Queue.

In ASFramework, there are threads as below.

Main	You can increase or decrease the Worker thread's pool number, or monitor the Worker thread's processing time at intervals according to the queue size by the ASFramework's thread.
Control	The thread is used to return the response to the operational request and the stop request from ASTERIA Monitor.
Accepter	The thread is used to wait for the requests, and put the received requests to the queue.
Worker	The thread is used to take out the requests from the queue, and process them.

Execution model image

Moreover, ASFramework has core processes inside 1 physical process.

Execution models' image

FlowService's architecture

The FlowService consists of listeners and ASFramework process cores. The listeners are used to receive the requests from HTTP / HTTPS / AJP's each protocol, and the ASFramework process cores include the Flow processing core -- the Flow Engine etc.

FlowSerive concept image

The services running in the "server" have their own TCP port number, and there are listeners to monitor the access from external to the port number. All of the processes have listeners for controling, which is used to receive the operation monitoring signal from ASTERIA Monitor. Some services receive the access from the HTTP which is essential for providing their own services. For the port numbers used by each listener of the "server", please refer to the "Listener list" of the "the Flow Service Application Guide".

In the Flow Engine, Accepter receives the Flow start requests sent from the all listeners, and registers them to the Queue immediately. Then, the pooled Workers in free state take out the first request from the Queue, and begin to process it. The Worker processes the Flow (The mail Flow including SubFlow and Exception )from begin to finish. Once finished, it return to the free state.

The Worker is keeping data like the Flow variable and stream etc. while calling out each component from the Flow in order from the Start Component until the End Component.

About the thread tuning through the listener

In the Flow Service, there is an ASFramework installed in each listener like HTTP, so each listener has a thread like Accepter or Worker, and Queue. Moreover, the listener's Worker has to wait the response (namely the Flow finished) from the Flow Engine, so althouth it is active, yet sometimes idling threads (state only waiting for the response) will appear. For example, when you call out a Flow through HTTP, once there is another level added into the requests, at least 1 HTTP listener's Worker thread and 1 FlowEngine's Worker thread will be added. It's a basic tuning method.

Moreover, even if the HTTP listener is active, because the idling (low CPU consumption) time is a little longer, yet it can be effective to shorten the gap between the ususal pool number and the maximun pool number. Conversely, when the Flow Engine is active, the CPU utilization is usually high, so by increasing the usual pool number a little, and only combining the maximun pool number to the HTTP listener, you can save the memory and the CPU consumption from inactive thread (increase allocations to other services).