Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 2.0.0-M1, 2.0.0-M2, 2.0.0-RC1
-
Component/s: Transport: VM
-
Labels:None
-
User impact:High
-
Similar Issues:None
Description
Currently the VMMessageReceiver inherits TransactedPollingMessageReceiver. Polling message receivers are really only necessary for transports for which picking up a message is "expensive"; since this transport is local to the same JVM, this condition does not hold; unfortunately this also prevents the VM receiver from being used in configurations where many in-VM events must be received rapidly, since the polling is controlled by the connector's scheduler (which is the right thing to do for all other transports, VM is just the exception to the default rule). Note that this was also true in 1.3.
The emergency fix in MULE-1688 works fine but was only a workaround: similar to JMS XA polling, polling workers are regularly triggered by the scheduler but not if they are already polling/busy, in which case the scheduler thread immediately returns.
The "real" solution would be to make VMMessageReceiver work in a similar fashion to the rewritten non-XA JMS receiver. See my comment on MULE-1688 why I haven't done that yet.
Progress note - results from a very elegant solution to all this:
previously:
msgs/sec: 74
msgs/sec: 93
msgs/sec: 93
msgs/sec: 93
msgs/sec: 93
msgs/sec: 93
msgs/sec: 93
msgs/sec: 93
msgs/sec: 93
msgs/sec: 93
now:
msgs/sec: 3232
msgs/sec: 8000
msgs/sec: 9416
msgs/sec: 8635
msgs/sec: 8000
msgs/sec: 7112
msgs/sec: 8650
msgs/sec: 8896
msgs/sec: 9398
msgs/sec: 9416
This is with queueEvents=true, still polling and transparently integrated into the current code with minimal changes. Also now has much better concurrency (uses the receiver's workManager correctly); throughput is achieved by message batching, though without stalling for single messages or slamming the threadpool too hard in case too many messages are queued.