In Fuse Message Broker, a cursor is used to hold a batch of messages in memory, while those messages are waiting to be sent to a destination. By default, the batch of messages is pulled out of the message store and then held in the cursor (this is the store cursor).
Fuse Message Broker has another cursor implementation, the VM cursor, which can be significantly faster in some cases. With the VM cursor, incoming messages are inserted directly into the cursor, bypassing the message store (the messages are also, concurrently, inserted into the message store). This works well if the consumers are fast and are able to keep up with the flow of messages. On the other hand, for slow consumers this strategy does not work so well, because the VM cursor fills up with a backlog of messages and then it becomes necessary to invoke flow control to throttle messages from the producer.
To configure a broker to use the vmCursor
for all topics
and queues, add the following lines to your broker
configuration:
<broker ... > ... <destinationPolicy> <policyMap> <policyEntries> <policyEntry topic=">"> <pendingSubscriberPolicy> <vmCursor /> </pendingSubscriberPolicy> </policyEntry> <policyEntry queue=">"> <pendingSubscriberPolicy> <vmCursor /> </pendingSubscriberPolicy> </policyEntry> </policyEntries> </policyMap> </destinationPolicy> ... </broker>
Where both the topic and queue entries specify the wildcard, >
, that
matches all destination names. You could also specify a more selective destination
pattern, so that the VM cursor would be enabled only for those destinations where
you are sure that consumers can keep up with the message flow.
For more information about the Fuse Message Broker cursor implementations—, and the advantages and disadvantages of each one—see Message Cursors in Using Persistent Messages.