BackGroundMethodServer queues overloaded during mass changes
Hi,
We have experienced the Background Method Server queues being very busy due to mass changes. This causes smaller background jobs to be placed at the end of the queue and users have to wait several hours before their job is processed.
Example.
- Change initiated on a part that is used in many bom’s
- All kinds of activities are send to the queue. e.g.
- Promotion / Set state jobs
- ESI sendings
- Etc.
- All of this is processed in the WFPropagationQueue, which obviously takes some time to process.
- But, when other user then does some simple stuff like promote, set state, start NC, etc, there job will be placed at the end of the queue.
- This causes frustration among our users, and they think, the system did not catch their first attempt. Eventually they perform the same action multiple time and complain about a slow system.
So, now I would like to find a solution, where these long running jobs can mind their own business, while other jobs can be processed in parallel, if possible.
I have read some articles in the knowledge base about setting up multiple background Method Servers and how they can be configured to take care of different queues, but I am not sure how to get to a result that will solve our issue.
Anybody with experience or good ideas?
/Kim