let me show the data extracted from wf_deferred_table_m to explain the issue:
We have schedule a workflow background process for item type GLBATCH to run every 2 minutes.
From the table wf_deferred_table_m, it shows:
GLBATCH 90869*3047 0 = Ready 1 2/12/2007 7:32:01 PM 2940BAE418A09076E0430AF0084A9076
GLBATCH 90866*3045 0 = Ready 1 2/12/2007 7:32:14 PM 2940BAE418A29076E0430AF0084A9076
GLBATCH 90868*3046 0 = Ready 1 2/12/2007 7:32:10 PM 2940BAE418A19076E0430AF0084A9076
This means there are three deferred activities are the queue.
Each activity will call a program to submit the journal import program
1. The first activity on the queue will submit the journal import program. After the journal import program was completed, the first activity will be removed from the queue (the table wf_deferred_table_m).
2. Then another journal import will be submitted and run. Again, after the journal import program was completed, the second activity will be removed from the queue.
3. Again another journal import will be submitted and run. After the third journal import program was completed, the last one in the queue will be removed and the queue will become empty now.
It seems that there will be always 'one' queue to process the deferred activities, and the deferred activities are processed one by one, waiting the previous to be completed first.
In this case, if the queue is long, and every time one one deferred activity is being processed, it will take a very long time to complete the whole queue.
We wonder whether this is a normal behaviour, and is there any way to speed up the dequeue process.
Please kindly help and advise. This affects the design of the workflow to run.