Thank you for your quick response.
I was able to sign up for the jira system, attach the test case and comment
on the issue, but I couldn't figure out how to reopen it. I don't know if
it's a permissions problem or if I'm just not seeing the button. Can you
reopen the issue as you suggested?
I am using activemq-core-5.7.0.
We are using broker-to-broker communications with conduit subscriptions to
reduce redundant messaging. We have a top-tier coordinating server, call it
broker A. We have two routing servers that each connect to A, call them
broker B and broker C. We have remote
It appears mixing and * just won't work if topic. matches a
topic.* subscription and gets ignored. We will be configuring an
appropriate number of levels to subscribe to and use a topic.*,
topic.*.*, topic.*.*.*, etc progression. Unless I'm misunderstanding
something else, this will give us a
gtully wrote
the combination of networkConnector *name* attribute and brokerName of
a network needs to be unique.
Use a different name for each configured networkConnector element on a
given broker.
Calling setName or setBrokerName with a unique string on the
NetworkConnector appears
Guerrero wrote
Using ActiveMQ 5.5.1.
...
Is there some configuration that I'm missing or is this fixed in 5.6.0, or
something that just isn't supported?
Update: I've upgraded to 5.6.0 and am still seeing this behavior. More
debugging to be done.
--
View this message in context:
http
With this default behaviour, N subscriptions on a remote broker look like
a single subscription to the networked broker.
This is something we desire. For instance, A.appId is the central broker,
and A.B.appId, A.B.C.appId, and A.B.D.appId are all connected to A.appId.
When A.B.D.appId send
Using ActiveMQ 5.5.1.
We have several applications connected in a mesh network, but impose a
hierarchy on application messages with a tree of wildcard subscriptions.
Heartbeats are broadcast to all ancestors, descendants, and direct siblings
for some internal housekeeping, but our wildcards don't
