We're testing network of brokers using brokerPath to validate which brokers the message visited. Based on our observations, "brokerPath" is not a message property or header, and the only way to access it is casting message to ActiveMQMessage. No need to explain why this is not ideal; is there no alternative?
You could always subclass the plugin and change it as you wish.
On 24 Mar 2016 8:08 p.m., "Raffi" <[hidden email]> wrote:
> We're testing network of brokers using brokerPath to validate which brokers
> the message visited. Based on our observations, "brokerPath" is not a
> message property or header, and the only way to access it is casting
> to ActiveMQMessage. No need to explain why this is not ideal; is there no
> TextMessage message = ...
> log("exists: " + message.propertyExists("brokerPath")); //false
> ActiveMQTextMessage amqMessage = (ActiveMQTextMessage)message;
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Why-is-brokerPath-not-a-message-property-tp4709942.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Hmm, why is it not ideal to cast to an ActiveMQMessage when validating an internal operation of ActiveMQ? Is there another messaging provider that gives the exact same information and, therefore, a need to make this code reusable across both?
BTW, I suspect you'll find validating the path messages take across a network of brokers to be very enlightening, assuming the NOB is using demand-forward bridges. Makes me wonder the reason for the testing as it's really testing the internals of ActiveMQ's operation.
If there's a need to ensure messages flow across the NOB in a specific pattern, then it will be necessary to use static routing, or somehow implement routing logic directly (such as through camel routes). The internal handling with demand-forwarding is complex. Part of the reason for this complexity is the fact that producers and consumers on the same destinations can be anywhere across the network, and the demand-forwarding broker network has to make sure messages always make their way to consumers, no matter where they connect. In fact, messages can flow in "contradictory" directions with multiple producers and consumers distributed across nodes, or with producers and consumers moving around the network over time. An example of Contradictory flow is messages flowing from broker A to broker B on a Queue at the same time messages flow from broker B to broker A on the same Queue.