huge number of documents are struck in broker queue, problem for processing those

Hi Guys, We are facing problem with trigger to get the documents from the broker queue. Every week, there were thousands documents left in queue and processing those document in production server is big challenging for us. As per project requirement, One trigger is created and subscribing the multiple documents to the multiple services. And trigger processing is concurrent mode. Currently 10 different documents are subscribed from the broker queue and processing to 10 different subscribing services. Some subscription services contain the filter conditions and some are didn’t have those. Currently the Trigger capacity level is ‘24’ and refill level is ‘8’ and acknowledgement queue size is ‘4’. The subscription service logic executed properly. Trigger Management, control like below, Document retrieval and document processing level are below, 1) Maximum Threads are 150 (100% of server thread pool) 2) Queue capacity throttle 100% 3) Execution capacity throttle 100% But daily, there are thousands of documents are in queue and processing those documents to target system will be in very delay. Currently using the pub-sub logic in the flow and all the documents are guaranteed documents. Currently the server is wM version61. And broker also in 6.1 version only. Kindly please help us to resolve the issue, to process the documents quickly. We did, following activities, 1) Shutdown the server, shutdown the broker, shutdown the repository server and start the server’s one by one. At the restarting the servers, the document processing bit fast for some time, and later, it comes to the normal state and documents will be high in the broker queue for processing. Thanks and Regards, Srinivas

Filled up queues are mostly caused by slow processing in the triggered services. So I recommend checking if there is a bottleneck in processing. Check with IS Service usage if all threads are used up.

I prefer having one trigger per document. This makes managment and tuning a lot easier.

You write, you have 10 different services in one trigger. This is far to much for your queue settings, but instead of increasing those I would distribute to different triggers. What is your setting for max execution threads for the trigger? This defines how many parallel executions are possible. Is 150 is your number here, the queue capacity and refill as much to small, because this defined how may can be taken to the IS at one time. Having 150 threads but refill 8 is not well balanced. Be also aware that docuemnts are not aknowledged ebfore they are successfully processed.

So my recs:
Distribute to different triggers.
Check which one is performing bad yet.
Check performance of processing service.