Hi,
we are currently encountering the following issue with one of our process models which uses correlation:
Assuming the following scenario:
Process gets started normally and then waits for the correlating documents.
When the right number of correlating documents has arrived and joined the process, the process finishes its work and completes regularly.
Upon completion the correlation id gets deleted from WMPRTXREF table to avoid further correlations to the completed process instance.
But the process itself is still visible in the database for 45 days before it gets deleted via Monitor archiving.
Now we have the issue, that sometimes the sender of the correlating documents sends us further messages which will be correlated to the still existing process instance within these 45 days.
As the correlation id is no longer in the database due to the completion, the documents are not processed by the subscription trigger of the process model but stay in the Broker Queue for the subscription trigger undefinitely.
When there are 10 or more of these documents in the queue the subscription trigger for this model blocks and all other messages (either starting or correlating) are stuck in the Broker until these odd messages are removed from the Broker queue and IS is restarted to free up the local trigger queue cache of these documents.
Environment is wM 9.12 with Broker 9.6 and IS_Core_Fix23, MON_Fix17, PRT_Fix15 applied.
And now here are the questions:
Why cant the documents be discarded from the queue when the instance they should correlate to is already in completed state, but still existing?
I guess, that after the moment the instance has been archived/deleted, the additional documents will be discarded directly as there is no instance any longer to which they could correlate.
Is there anything we can do to avoid these messages filling up and blocking the trigger queue on the Broker?
The whole process of identifying and removing these messages from the Broker queue, stopping and starting the IS takes approx.30 minutes for one round as IS will not stop in time and gets killed by the Tanuki wrapper, which causes several “FSData full consistency checks” during startup.
Thanks in advance for any helpful response.
Regards,
Holger