Why is brokerPath not a message property?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is brokerPath not a message property?

Raffi
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?


TextMessage message = ...
log("exists: " + message.propertyExists("brokerPath"));  //false
ActiveMQTextMessage amqMessage = (ActiveMQTextMessage)message;
amqMessage.getBrokerPath();
Reply | Threaded
Open this post in threaded view
|

Re: Why is brokerPath not a message property?

Raul Kripalani-3
You could always subclass the plugin and change it as you wish.

Cheers,
Raúl.
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
> message
> to ActiveMQMessage. No need to explain why this is not ideal; is there no
> alternative?
>
>
> TextMessage message = ...
> log("exists: " + message.propertyExists("brokerPath"));  //false
> ActiveMQTextMessage amqMessage = (ActiveMQTextMessage)message;
> amqMessage.getBrokerPath();
>
>
>
>
> --
> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Why is brokerPath not a message property?

Raffi
Yup, that's always an option too, :-)

thx
Reply | Threaded
Open this post in threaded view
|

Re: Why is brokerPath not a message property?

artnaseef
In reply to this post by Raffi
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.