About "round robin" polling
Round robin polling is a special, separate polling thread in the Infor Framework services that proceeds through configurations/databases and processes them one at a time.
For example, the Infor Framework TaskMan service asks the database, at intervals set up for the intranet, whether it has anything to do. This is the Infor Framework service-level polling cycle.
Round robin polling sits over that (as well as the other Infor Framework services) as a higher-level polling manager. When the internal polling for TaskMan wakes up, before it does its usual database request to see if there is anything to do, it now checks to see if the round robin polling manager has told it to do something or not. If the round robin polling service has not, TaskMan goes back to sleep until the next polling cycle. If the round robin manager has made a request to TaskMan, TaskMan then asks the database if there is anything for it to do.
Round robin polling inherently introduces latency, especially in multi-tenant cloud environments. To help offset this, round robin polling handles polling activity in batches, in which it processes a specified number of configurations/databases at one time. The size of each batch can be specified, using the Round Robin Batch Size process default. This batch size is the number of configurations/databases the polling service is to handle at each go. Instead of looking at just the next configuration/database then, it looks at the next batch of configurations/databases.
A second process default is typically used in conjunction with the Round Robin Batch Size process default, to help control exactly how batches are processed. This second process default is the Round Robin Polling Interval. This polling interval specifies how long the round robin polling is to wait between the end of one batch's processing and the retrieval of the next batch to process. This interval is specified in milliseconds.
The interaction between these two process defaults means that, if you have a large polling interval and a small batch size, latency goes up, and this slows things down. If, on the other hand, you have a small polling interval and a large batch size, latency goes down; but it can be at the cost of polling efficiency. The key is to find the right relationship between the batch size and the polling interval.