There was a question been asked about the controlled execution in Oracle SOA suite. lets us understand the problem statement.
Lets say there is a batch process runs in Application A which produce a thousand number of messages which is been consumed by the SOA tier using jms adapter. In a normal scenario without any configurations, its will use total number of available threads (max - currently running) for the execution until reached total threads configured in system.
Now if the execution time of these processes are quite high then we defiantly want, messages to be processed in controlled way. Even we should be able to dictate TPS (transaction per second) in control execution.
There are two ways we can see in the current Oracle weblogic/soa suite architecture,
Setting Minimum Time delay
We can configure number of threads to be processed and also we can set a delay time in processing between two messages.
Lets say if we set a delay time of 1 second and execution time of each process is .5 second then thread will wait to for .5 second to poll for next message. If the process will run for 1 second then it will allow adapter to poll next message instantly as process finish. Hence the wait time is an inclusive of configured execution time delay.
<property name="InboundThreadCount">2</property>
<property name="minimumDelayBetweenMessages">10000</property>
In Oracle SOA - 12c the concept of the resource allocation has been changes to work managers, work manager can be think like a manager been given a list of objective, which it need to achieved. Manager objectives are clearly defined in underlying properties which is been generated automatically when we create a work manager group. These property individually cover different engine
We can clearly see that folder has assigned a group work manager. This group work manager has a lot of work manager under it, we can even change the work manager assign to folders from the above screen.
These work managers have properties to control the resource allocation and provide the priorities of each engine. This can be seen
Hence by using all the above screen we can decide to change resource allocation of thread which we are planning to give to each engine.
From the above its very clear that work manager is quite high level and control all the resource/composite under a partition, with the rules defined in the work group. While if we aim to control thread at jms level then it will be quite granular and we can even decide transaction per second to be executed using JMS.
Lets say there is a batch process runs in Application A which produce a thousand number of messages which is been consumed by the SOA tier using jms adapter. In a normal scenario without any configurations, its will use total number of available threads (max - currently running) for the execution until reached total threads configured in system.
Now if the execution time of these processes are quite high then we defiantly want, messages to be processed in controlled way. Even we should be able to dictate TPS (transaction per second) in control execution.
There are two ways we can see in the current Oracle weblogic/soa suite architecture,
Setting Minimum Time delay
We can configure number of threads to be processed and also we can set a delay time in processing between two messages.
Lets say if we set a delay time of 1 second and execution time of each process is .5 second then thread will wait to for .5 second to poll for next message. If the process will run for 1 second then it will allow adapter to poll next message instantly as process finish. Hence the wait time is an inclusive of configured execution time delay.
<property name="InboundThreadCount">2</property>
<property name="minimumDelayBetweenMessages">10000</property>
Setting work Manager.
In Oracle SOA - 12c the concept of the resource allocation has been changes to work managers, work manager can be think like a manager been given a list of objective, which it need to achieved. Manager objectives are clearly defined in underlying properties which is been generated automatically when we create a work manager group. These property individually cover different engine
We can clearly see that folder has assigned a group work manager. This group work manager has a lot of work manager under it, we can even change the work manager assign to folders from the above screen.
Hence by using all the above screen we can decide to change resource allocation of thread which we are planning to give to each engine.
From the above its very clear that work manager is quite high level and control all the resource/composite under a partition, with the rules defined in the work group. While if we aim to control thread at jms level then it will be quite granular and we can even decide transaction per second to be executed using JMS.
No comments:
Post a Comment