...
</destinationInterceptors>
... Note that making a topic virtual does add a small CPU overhead when sending messages to the topic but it is fairly small.
Option |
Default |
Description |
selectorAware |
false |
only messages that match one of the existing subscribers are actually dispatched. Using this option prevents the build up of unmatched messages when selectors are used by exclusive consumers |
local |
false |
when true, don't fan out messages that were received over a network |
concurrentSend |
false |
when true, use an executor to fanout such that sends occur in parallel. This allows the journal to batch writes which will reduce disk io (5.12) |
transactedSend |
false |
when true, use a transaction for fanout sends such that there is a single disk sync. A local broker transaction will be created if there is no client transaction (5.13) |
dropOnResourceLimit |
false |
when true, ignore any ResourceAllocationException thrown during fanout (see: sendFailIfNoSpace policy entry) (5.16) |
Composite Destinations Composite Destinations allow for one-to-many relationships on individual destinations; the main use case is for composite queues. For example when a message is sent to queue A you may want to forward it also to queues B and C and topic D. Composite destinations are then a mapping from a virtual destination to a collection of other physical destinations. In this case the mapping is broker side and the client is unaware of the mapping between the destinations. This is different from client side Composite Destinations where the client uses a URL notation to specify the actual physical destinations that a message must be sent to. ...
</destinationInterceptors>
... By default, subscribers cannot consume messages directly from a composite queue or topic - it is a logical construct only. Given the configuration above, subscribers can only consume messages from FOO and BAR ; but not MY.QUEUE . ... </forwardTo> </compositeQueue> ... Messages sent to IncomingOrders will all be copied and forwarded to Notifications , before being placed on the physical IncomingOrders queue for consumption by subscribers. ... </virtualDestinations> </virtualDestinationInterceptor> </destinationInterceptors> ... Avoiding Duplicate Message in a Network of Brokers ...
</networkConnector> </networkConnectors>
... |