Controlling the number of "CNO for Visibility" concurrent worker threadsControlling the Maximum Number of Concurrent Worker Threads Messages sent by the CNO for Visibility clients (a.k.a Informers) running in the Kubernetes clusters are first placed in the ECC queue. Later on, they are routed to one of pre-configured event queues and handled by the corresponding scheduled job. By default, the system configures 4 event queues which are handled by 4 scheduled jobs. This ensures that "CNO for Visibility" will never use more than 4 concurrent worker threads across all the instance's nodes. This number should be sufficient for handling up to around 300 Kubernetes clusters. However, if the number of clusters is higher or clusters are going through frequent changes, you can increase the maximum number of concurrent worker thread up to 8. To do so, navigate to System Properties/All Properties and edit the property: sn_acc_visibility.k8s_informer_max_worker_threads. The values allowed are 1 to 8. Routing ECC Messages to Event Queues The default routing algorithm decides on the target event queue based on the last character of the informer internal name. The system converts this hexadecimal character to a number, divides it by the number in sn_acc_visibility.k8s_informer_max_worker_threads and takes the reminder. Example 1: Informer name: k8s_informer_4724f0d3-121a-4331-a9e0-7a91178d75a4 Last character: 4 Last character as a decimal number: 4 Queue number: 4 % 4 (sn_acc_visibility.k8s_informer_max_worker_threads) = 0 Message will be routed to event queue: sn_acc_visibility.k8s_informer.message_0 Example 2: Informer name: k8s_informer_8afc893b-d304-4e16-b345-d72871ad0d21 Last character: 1 Last character as a decimal number: 1 Queue number: 1 % 4 (sn_acc_visibility.k8s_informer_max_worker_threads) = 1 Message will be routed to event queue: sn_acc_visibility.k8s_informer.message_1 Custom Routing of ECC Messages The system allows to override the default routing algorithm by providing a script. The system property sn_acc_visibility.k8s_informer_randomize_func is optional and should be used if you need to change the routing algorithm. The value refers to the “API Name” field in a sys_script_include record. The script in this record will see a variable name called eccGr which is the glide record of the ECC message being processed. It should return a number between 0 and (sn_acc_visibility.k8s_informer_max_worker_threads – 1). It should be returned as a string. The script should always return the same result per a given cluster. This will ensure that all messages from a given cluster will be processed in the order they arrive. Example: In this example, messages from a couple of clusters are routed to a dedicated queue while all the rest are routed to a third queue. In this example, the system property sn_acc_visibility.k8s_informer_randomize_func should have the value sn_acc_visibility.randomizeInformerQueue. The outcome of the code in this example is that messages from two specific clusters will be routed to a dedicated queue (queue 0 and queue 1), while messages from all other clusters will be routed to queue 2.