Hi everyone, I am facing a concurrency issue when consuming messages from a Non-Exclusive queue using the Mule 4 Solace Connector. As a baseline, I built a native Java application using the JCSMP API that scales perfectly to 20 concurrent consumers, reading and processing messages extremely fast in parallel. The Java implementation achieves this by establishing a single shared JCSMPSession and using a thread pool where each of the 20 threads creates and manages its own FlowReceiver bound to the queue. While this multi-flow architecture works flawlessly in native Java, I am struggling to replicate this behavior in Mule 4.
In my Mule 4 application, I configured a flow starting with a Guaranteed Endpoint Listener and explicitly set the flow’s maxConcurrency to 20. I also ensured that the “Process next message after Flow completion” advanced setting is disabled, expecting the connector to feed messages to the flow’s worker threads concurrently. However, the connector behaves as a strict single-threaded funnel. The Solace broker registers only 1 Consumer bound to the queue, and the message throughput indicates that the listener is fetching and processing messages strictly sequentially (one by one), failing to utilize the 20 concurrent threads available in the Mule flow.
The only way I have been able to observe true concurrency and get multiple consumers registered on the Solace broker is by scaling horizontally, adding a second Mule worker/replica. Attempting to force vertical scaling on a single instance by physically duplicating the flow configuration (placing multiple Guaranteed Endpoint Listeners pointing to the same queue in the same app) did not work well either, failing to replicate the multiple network bindings I get effortlessly in Java.
Since the Mule 4 Solace Connector doesn’t seem to expose a concurrentConsumers parameter, how can we achieve true vertical scaling (multiple concurrent consumers or bindings) for a single queue on a single Mule instance? I would like to know if this strict single-threaded listener behavior is a fundamental architectural limitation of the connector. Any insights or recommendations would be greatly appreciated. Thanks in advance.