Open topic with navigation

TIBCO iProcess® Engine 11.9.1

# Configuring How Work Queues are Filtered

Multi-threaded filtering introduced in 10.4 by CR17284.

When filter criteria are applied to a work queue - for example, only show work items started by a particular user - the `WIS` process has to filter the work queue to find the correct items to display.

By default, the `WIS` process uses the thread that is processing an RPC request to perform any work queue filtering required by that RPC request. This is perfectly adequate if the queues are small and the filter criteria are simple. However, the time taken to filter a queue can increase significantly as the number of work items in the queue grows and/or the complexity of the filter criteria increases. This can result in a perceptible delay for the user viewing the work queue.

For example, filtering a queue that contains over 100000 work items using filter criteria that includes CDQPs can take over 6 seconds. (Obviously, CPU availability on the machine is also a factor in determining how long the filtering operation takes.)

To cope with this situation, the `WIS` process contains a pool of queue filtering threads that can be used to filter work queues more quickly. The following process attributes allow you to configure how and when these threads are used:

| • | WIS_FILTER_THREAD_BOUNDARIES allows you to define when a work queue should be split into multiple "blocks" of work for filtering purposes. You can define up to 4 threshold values for the number of work items in a queue. As each threshold is passed, an additional block of filtering work is created, which will be handled by the first available queue filtering thread.

| • | WIS_FILTER_THREAD_POOL_SIZE allows you to define the number of queue filtering threads in the pool. These threads are used to process all additional filtering blocks generated by the WIS_FILTER_THREAD_BOUNDARIES thresholds. Increasing the number of threads in this pool allows more blocks of filtering work to be processed in parallel, but at the cost of increasing the CPU usage of the `WIS` process.

For example, consider the following scenario:

| • | A work queue contains 180000 work items.

| • | WIS_FILTER_THREAD_BOUNDARIES has been set to create additional filtering blocks when a queue contains 100000 and 150000 work items.

| • | The `WIS` process receives 5 RPC requests to filter the queue.

Each RPC request on the queue generates 2 additional filtering blocks (each of 60000 work items). The first filtering block is still handled by the RPC processing thread that is handling the RPC request.

The 5 RPC requests, therefore, generate 10 blocks of additional filtering work to be processed by the queue filtering threads. If WIS_FILTER_THREAD_POOL_SIZE is set to:

| • | 10 or more, each block is immediately filtered by one of the queue filtering threads.

| • | less than 10, some blocks will have to be queued until a queue filtering thread is available to process them.

Note: When altering the WIS_FILTER_THREAD_BOUNDARIES, WIS_FILTER_THREAD_POOL_SIZE or RPC_SVR_CONTROL process attributes, you should bear in mind that the more RPC processing threads there are and the larger the number of work items in a queue, the more threads in the queue filtering thread pool will be used by a single RPC request to filter a queue.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO iProcess® Engine

Copyright © 1994-2024. Cloud Software Group, Inc. All Rights Reserved.