CODEWITHSUNDEEP
batch-filequeuetimeoutmuletransient
gtx911
gtx911

Reputation: 1289

Mule 4 - Empty VM queue error consuming messages

I have a flow in Mule 4 that reads data from a CSV file and inserts it into Salesforce using a Batch:

mule flow

All Salesforce results are inserted into a non-persistent VM queue (transient by default).

All messages are inserted for each block of records and are consumed without problems at the end of the batch.

However, when I have finished, the following error appears after 10 seconds:

Message               : Tried to consume messages from VM queue 'productQueue' but it was empty after timeout of 10 SECONDS.
Error type            : VM:EMPTY_QUEUE
Element               : testing-threadingSub_Flow/processors/0/processors/0 @ testing-threading:testing-threading.xml:95 (Consume)
Element XML           : <vm:consume doc:name="Consume" doc:id="6b7b2df6-c986-425c-a6f0-29613a876d37" config-ref="VM_Config" queueName="demoQueue" timeout="10"></vm:consume>

Why does the consumer of the queue run if there are no more messages to process?

I want this component to only read messages when it is his turn. Maybe I'm using the wrong kind of VM?

Upvotes: 0

Views: 1627

Answers (1)

Ryan Carter
Ryan Carter

Reputation: 11606

The VM consume operation will try reading from queue up to a specified timeout which is configurable and then log that error if the queue is empty.

Somehow your foreach block is executing the consume more times than the required amount/messages available. If you share you foreach xml configuration we might be able to see more as to why.

Other than solving why foreach is running the consume more than necessary. There are a few options to modify this behaviour:

Wrap the consume in in a try to supress the error:

 <try doc:name="Try" >
                <vm:consume ... />
                <error-handler >
                    <on-error-continue enableNotifications="false" logException="false" type=" ">
                        <logger  />
                    </on-error-continue>
                </error-handler>
            </try>

Or maybe do not use a consume, and use a different flow with a VM listener to listen for the messages on that VM queue. This might change how your app needs to work.

Upvotes: 3

Related Questions