Processing Queue (Object)

STUB	This article is a stub. It contains minimal information on the topic and should be expanded.

memory Processing Queue node objects are designed for tasks performed by computer Machines and their Activity Processing services. Processing Queues are used to distribute Grooper "Code Activity" tasks among different servers and control the concurrency and/or processing rate of these tasks.

• For example, activities such as Render or Export can be managed so that only one activity instance runs per machine or so multiple instances are processed concurrently, according to the queue configuration.

This is accomplished by following these general steps:

1. Create a new Processing Queue
2. Assign it to a step in a Batch Process using its Queue Name property.
3. Create an Activity Processing Grooper Service from Grooper Config.
4. When configuring the Activity Processing service, select the Processing Queue using the Queue Name property.
5. Specify how many threads you want to run using the Number of Threads property.

FYI

Prior to version 2022, Processing Queues were known as "Thread Pools". While the name is different, their purpose, configuration, and functionality is largely identical. The only difference is prior to version 2022 there was a "Default" Thread Pool object added to every newly initialized Grooper Repository. There is no corresponding "Default" Processing Queue object. Rather, the default Processing Queue is assumed if a Batch Process step does not reference a Processing Queue in its Queue Name property.

About

Processing Queues meter how many tasks are able to be processed at a single time by restricting how many CPU threads are available for processing. There are a number of reasons why you would want to restrict the number of available threads:

• You may want to throttle certain processor intensive Grooper Activities in order to free up compute for other Activities. Processor intensive Activities (such as the Recognize activity) can "bottleneck" computing resources. By limiting the number of threads that process such tasks, you can free up threads for less processor intensive activities. This can allow for more Batches to be processed at the same time, reducing the number of Batches that otherwise would be waiting for available threads while all system resources were devoted to a series of tasks for a single step.
• Processing Queues can control the concurrency of operations to an external system. Imagine you are exporting to a content management system using a CMIS Connection. Assume your system has 64 threads available for processing. If the content management system allows 64 concurrent connections (allowing 64 documents exporting at a time in this case), then there's no problem. The system has one thread for each document exporting to the content management system. The Export activity would run with no problems. However, what if the content management system only allows for 16 connections at a time? Grooper is going to try and use all 64 threads to export unless told otherwise. The first 16 documents might export with no problems, but the next 48 (64 threads minus 16 threads) will error out. By creating a Processing Queue using only 16 threads for the Export activity, Grooper will hold off from using all 64 threads for the activity. Only 16 threads (one for each allowable concurrent connection to the content management system) will be used at a time.
• Some activities only allow one instance of the activity to execute at a time per machine executing the activity (Namely, the Render activity). In such cases, you would first create a new Processing Queue, specifying a PerMachine for the Concurrency Mode property. Then, you would create an Activity Processing service, assign it the newly created Processing Queue and drop the number of available threads to one. Last, you would configure the activity's step in the Batch Process to run using the newly created Processing Queue instead of the "Default". By doing this, the activity will be forced to run on a single thread, one instance at a time, one server or workstation at a time. If another instance of that activity tries to run while the first is running (such as a second Batch running on the same machine trying to run the same activity already running in another Batch Process), the second will be forced to wait its turn.

FYI	More detailed information about how to add a new Processing Queue and assign it to an Activity Processing service can be found in the Activity Processing article.

Concurrency Mode

This property specifies the parallel processing mode for a Processing Queue. It controls how multiple Activities (or the machines processing Activities) pool system resources.

This can be set to one of three modes:

• Multiple - Multiple instances can run concurrently. Multiple occurrences of the Activities using the Processing Queue can run at the same time
• PerMachine - Only a single instance can run on a single machine. Only one occurrence of an activity can run on a machine at a time.
• Single - Only a single instance can run per Grooper Repository. Regardless of how many machines are connected to the repository attempting to run an activity, only one occurrence of an activity using the Processing Queue can run at a time.