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 seem to work consistently.
For example, we may have a root node A.appId that listens on "heartbeats.A.>" in order to receive information from direct siblings and children. A child, A.B.appId acts as a viewer and listens on "heartbeats.A.*" for its parents and "heartbeats.A.B.>" for direct siblings and children. A grandchild, A.B.C.appId listens on "heartbeats.A.*" and "heartbeats.A.B.*" for its parents and "heartbeats.A.B.C.>" for direct siblings and children. A grandchild, A.B.D.appId listens on "heartbeats.A.*" and "heartbeats.A.B.*" for its parents and "heartbeats.A.B.D.>" for direct siblings and children. After starting up A.appId, A.B.appId, and A.B.C.appId, we have the following subscriptions: heartbeats.A.> heartbeats.A.* heartbeats.A.B.> heartbeats.A.B.* heartbeats.A.B.C.> heartbeats.A.B.D.> The subscriptions are propagated to A.B.D.appId when it starts up and connects. If they are received in that order things seem to work. However, once every few times, we get the "heartbeats.A.*" and "heartbeats.A.B.*" subscriptions before it gets the "heartbeats.A.>" and "heartbeats.A.B.>" subscriptions. Debugging into the source, I see it get to ConduitBridge.addToAlreadyInterestedConsumers, and "heartbeats.A.*" matches "heartbeats.A.>", so it doesn't get added. Thus, the broker on A.B.D.appId doesn't have any external consumers of "heartbeats.A.B.D.appId", and nothing knows it came online. Is there some configuration that I'm missing or is this fixed in 5.6.0, or something that just isn't supported? -- View this message in context: http://activemq.2283324.n4.nabble.com/Wildcards-may-block-a-prefix-in-a-network-of-brokers-tp4654420.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
