Hello Issac,
You can follow below steps
If the qos_processor queues tend to backup and not drain but you don’t have any enrichment scripts configured you can set the following setting to avoid this situation:
Open the qos_processor probe and set:
enrichment-enabled = false
Then the qos_processor can process faster but still do origin lookups. This is often sufficient to keep the qos_processor queue from backing up.
Otherwise, if you do have alarm enrichment scripts in place, you can adjust the following settings:
Make sure you have enough physical memory to spare and increase the startup options of the probe:
java_mem_init
-Xmx2048m
and
java_mem_max
-Xmx4096m
and set message-receiver-bulk-size
to 2000 (as recommended by Development).
Make sure you also set the data_engine's bulk_size to 999 using the hub Raw Configure window->postroute section.
To remedy the situation right away you can usually just restart the probe but if you have a lot of messages queued, you may have to wait for it to drain after making the changes in 1 and 2 above.
As a fallback, if none of he above works as expected you might have a corrupted message in the qos_processor's .sds file. That .sds file is just a copy of the messages so it can be deleted after stopping the robot, if need be. Then activate the robot again.
Alternatively if really necessary, you could set up an AO profile to run a command to restart the qos_processor probe periodically or use an AO profile to restart it when the queue size reaches a specific size (You can right click and select edit the probe and sepcify time period in time specification).