On Wednesday 01 October 2008, Joe Fernandez said: > Use care, if you've assigned the multicast uri to all the brokers' network > and transport connectors. They'll all end up trying to connect to one > another. I think what you may want to consider is more of a hub-n-spoke > topology, where the hub is your master broker. The resulting connections > (spokes) in that topology would have to be 'duplex' in order to accommodate > two-way traffic.
Ok, I've got everything duplex. I'm not using multicast - I couldn't get the windows boxes to allow that. So the embedded brokers all connect to a central broker, in the central office, even the server processes in the central office. I don't really see a way around using the embedded brokers in the field, though. The messages seem to get enqueued in the embedded brokers and then not beyond that, they don't get dequeued when the client on the other end comes up. So it feels as though the subscriptions aren't being communicated or they arent' really durable or something. But I'm not sure. > > conduitSubscriptions > -------------------- > This example helps explain “conduitSubscriptions”. Suppose you have two > brokers, A and B that are interconnected. Connected to broker A, you have a > consumer that subscribes to a queue called Q.TEST. Connected to broker B, > you have two consumers that subscribe to the same queue. Then you start a > producer on broker A that writes 30 messages to Q.TEST. If > conduitSubscriptions=true, 15 messages will be sent to the consumer on > broker A and the resulting 15 messages will be sent to the two consumers on > broker B. This is because broker A views the two subscriptions on broker B > as one. If you set conduitSubscriptions to “false”, then each of the three > consumers is given 10 messages. Wow, that really makes sense. I guess I'll leave it false. But it *shouldn't* make any difference since we're sending assignments out to the field on personalized topics - there should only be one consumer for the messages. And only the server processes should be consumers for their particular topics. > > duplex > ------ > If true, a network connection between 2 brokers will be used to both > produce AND consume messages. In other words, messages can flow in either > direction. This is useful for hub and spoke scenarios when the hub is > behind a firewall or for clients implementing a request/reply protocol. > This is available only for ActiveMQ version 5.0 and higher. I'm using duplex = true. > > > dynamicOnly > ------------ > If set to true, the broker will forward messages to the endpoint broker > (broker at the other end of the connection) only if that endpoint broker > has active consumers. I've got this set to false. I had actually hoped when I read this that I had it set to true, because it would seem as though it might be the solution to my problem - but it is set to false in all 3 brokers. Well - maybe I should *try* it true, just to see? > > > Joe > Get a free ActiveMQ user guide @ http://www.ttmsolutions.com > > Joe Fernandez wrote: > > Are the 'assignments' messages being sent out as non persistent messages? > > > > Joe > > Get a free ActiveMQ user guide @ http://www.ttmsolutions.com > > > > Tom Corbin wrote: > >> Now, it seems like the recommendation is for Master/Slave for reliable > >> delivery, but I don't think we can do that. > >> > >> We've got field laptops which may or may not have connectivity with the > >> central > >> office, but they want to be able to run the application and have it send > >> messages that get delivered when the network comes up. > >> > >> And the client wants the central office to be able to send assignments > >> to the > >> field whether or not the network to the field laptop is up. > >> > >> So for the field laptops I've set up an embedded broker which then > >> connects to > >> a central office broker. The reason is that the application won't come > >> up if > >> there isn't a local broker that it can connect to. If the application > >> is started w/o a local broker or a connection to the central office it > >> doesn't come > >> up. Plus, I wanted the local message persistence so that the user of > >> the > >> application can trigger messages to be sent even when the connection to > >> the > >> central office isn't present. > >> > >> In the central office we've get server processes also with embedded > >> brokers. > >> > >> I've been fiddling with the setup configuration for the embedded brokers > >> and the > >> central office brokers and I've gotten to the point that messages from > >> the field > >> get sent to the central office on reconnect, but don't get sent from the > >> central > >> office to the field on reconnect. > >> > >> And everything works if everything is connected. But if the laptop > >> isn't > >> connected to the central office when the central office sends out > >> assignments to > >> the field, then the laptop will never see those messages. > >> > >> I've tried using durable subscription topics, I've tried setting > >> "conduitSubscriptions" to both true and false - and I'm not sure if I > >> should > >> set it one way for the central office broker and the same or different > >> for the > >> laptop and server process embedded brokers. > >> > >> The network kind of looks like this: > >> > >> Field laptop|---------|central office broker|-----|Server Process| > >> > >> The central office broker is intended to be the "master", in as much as > >> there is > >> a master - this isn't really a master/slave setup. > >> > >> I can use JMX to look at the enqueue/dequeue counts to see where > >> messages are > >> getting hung up - but I am not ever sure why. > >> > >> I had thought that with durable subscriptions, the messages would get > >> sent, > >> but that *seems* not to be the case. > >> > >> I have looked through ActiveMQ bug reports and the online documentation. > >> Of > >> which there is a lot, but I am still quite confused. > >> > >> Seeing as how I'm doing the embedded broker set up in Groovy, rather > >> than in > >> spring or xbean - should I explicitly be using a DemandForwardingBridge > >> as in > >> the ThreeBroker tests? Or does the underlying code just use it anyway? > >> > >> What would that imply for the activemq.xml config file for the master > >> broker? > >> Is there configuration that explicitly says use a > >> DemandForwardingBridge? Or > >> is the DemandForwardingBridge not the issue? > >> > >> What should these values be set to? > >> > >> decreaseNetworkConsumerPriority="false" > >> conduitSubscriptions="true" > >> bridgeTempDestinations="true" > >> duplex="true" > >> > >> Sorry for such a newbie set of questions and so long an email.
