On Wednesday 01 October 2008, Thomas R. Corbin said: > 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.
I forgot to mention that I'm on 5.1.0 -- Card #1. Uncle Bob’s Three Laws • Write no production code except to pass a failing test. • Write only enough of a test to demonstrate a failure. • Write only enough production code to pass the test.
