Your requirement that messages be routed in the absence of consumers/subscriptions (presumably that means you want the messages to stick around till a consumer shows up for them) drives you to needing to use queues, and selectors on queues could only allow you to route the original message to a single (possibly arbitrarily-chosen) consumer.
The use cases you described include the ability to route a single message to multiple arbitrary destinations, which can only be done by publishing additional clones of the original via something like Camel. (If you know the rules for how to fan them out in advance, you could use virtual destinations to do that instead of Camel, but from your description, I think you need more flexibility than that.) Camel is built with throughput in mind (it's a pipelined architecture with the ability to execute separate stages concurrently for different messages in order to keep throughput high), so although I've only run Camel as a standalone consumer rather than an embedded one, I would expect that you won't see too much of a performance overhead from running some embedded routes, as long as the business logic you're using to decide what to do isn't too heavyweight. The one potential impact is that if your messages are very large, fanning out multiple copies of them could add somewhat to the memory/storage load on the broker, but if your message sizes are reasonable then I don't think you'll experience unreasonable impacts. One observation: you'll see a lower performance impact if you can get all the information that you'd want your Camel route to evaluate and set them as header fields on the message when it's first published, so Camel doesn't have to go parsing the body of each message in order to grab that content. If you don't control the producers, that may not be possible, but if it is I'd definitely do that work there to keep the load on the broker lower. Tim On Fri, Apr 28, 2017 at 1:23 PM, Vince Cole <the.vince.c...@gmail.com> wrote: > Thanks, > > So the producer needs to set a destination. > That's OK, I guess it can be a 'special' destination, from which the broker > will perform routing to the appropriately determined destinations. > > PS the destinations won't be known in advance - they could be constructed > by > concatenating various parts of the message. > > My question is then: Can all of this be achieved via Selectors or do > Selectors require consumers, or pre-configured routes, to work? > > Similarly, would the Camel plugin be suitable for this? > > Finally, what effect would either of these have on performance/throughput? > > Many thanks once more in anticipation. > > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/destination-unspecified-can-ActiveMQ-set- > it-tp4725338p4725358.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
