NetworkConnector -> pattern to addDynamicallyIncludedDestination for tempQueue
we migrated activemq from < 5.5 version to 5.12.3. below is code snippet for
to create n/w connector
NetworkConnector networkConnector = new DiscoveryNetworkConnector(uri);
we are using Camel request/reply pattern with tempQueue. so our n/w
connector working only when we are removing =>
so either we need to remove or we need to provide this for TempQueue also.
TempQueue is starting with ID_
so, what pattern I need to give ? I tried different patterns like below
but none of these above are working. we need exact pattern to specify for
addDynamicallyIncludedDestination for tmpQueue also then only we will get
response otherwise we need to remove this addDynamicallyIncludedDestination.
so please suggest pattern & do we need to add it as new
ActiveMQTempQueue("ID PATTERN") or
new ActiveMQQueue("ID PATTERN") ? bcz if we add ActiveMQTempQueue I am
thinking this will not consider in n/w bridge.
> we migrated activemq from < 5.5 version to 5.12.3. below is code snippet
> to create n/w connector
> NetworkConnector networkConnector = new DiscoveryNetworkConnector(uri);
> we are using Camel request/reply pattern with tempQueue. so our n/w
> connector working only when we are removing =>
Is there any reason that you can't just do that? It's simple and you say it
works correctly for you...
> so either we need to remove or we need to provide this for TempQueue also.
> TempQueue is starting with ID_
> so, what pattern I need to give ? I tried different patterns like below
> but none of these above are working.
ActiveMQ wildcards only apply to one or more names in a path, but cannot be
used to specify variable content within a single name, so you can't match
"ID_SOMERANDOMNUMBER" with any of the patterns you mentioned, unless you
use a plugin to specify "_" instead of "." as the custom path separator for
name hierarchies. See http://activemq.apache.org/wildcards.html for
examples of what does work and details about the custom plugin.
> we need exact pattern to specify for
> addDynamicallyIncludedDestination for tmpQueue also then only we will get
> response otherwise we need to remove this addDynamicallyIncludedDestinat
> so please suggest pattern & do we need to add it as new
> ActiveMQTempQueue("ID PATTERN") or
> new ActiveMQQueue("ID PATTERN") ? bcz if we add ActiveMQTempQueue I am
> thinking this will not consider in n/w bridge.
If I'm reading the code of
DemandForwardingBridgeSupport.startRemoteBridge() correctly, you don't need
to explicitly include temp destinations, you just need to ensure that
NetworkBridgeConfiguration.isBridgeTempDestinations() is true (the default
value). So if not calling addDynamicallyIncludedDestination() causes things
to work, that seems like the right solution for you to use.
if we remove addDynamicallyIncludedDestination, then not only queue, even
topic messages also replicated to another broker
am I right ? this is the only reason we just want to restrict to some
we dont want any of ActiveMq.Advisory. topics to be replicated.
If you don't forward advisory messages, you can't do dynamic forwarding of
destinations, and you have to configure everything statically, which is
what the two other posters in that other message thread were trying to do.
See http://activemq.apache.org/advisory-message.html for more information
on what advisory messages are, and for the warning about needing to
statically configure your network if you turn them off.
bcz we dont
know what other things go wrong.
That sounds like FUD (fear, uncertainty, and doubt), which is a poor reason
for any decision. The only downside to forwarding advisory messages is a
small amount of extra network traffic and a small amount of extra CPU use
on the brokers. The cost is more complicated configuration, and to me that
is by far the higher cost. My advice is to just forward the advisory
If nothing happens even if we dont provide addDynamicallyIncludedDestination
then we are ok otherwise as much as possible we want to restrict by using
also by default bridgeTempDestinations is true, still message from
tempDestinations are not replicating.
Did you explicitly exclude the advisory topics, or just not explicitly
include them? If you don't see the corresponding advisory topic pass a
message when a consumer conn, you'll never see the real destination pass
one (unless you switch to static configuration, and I don't recommend that
based on what you've told us so far). So if you want to troubleshoot this,
start with the advisory messages.