On Thursday 02 October 2008, Joe Fernandez said: > Are your 'assignments' messages are being sent out as non persistent? If > so, then that is more than likely your problem. > > http://activemq.apache.org/why-do-i-not-receive-messages-on-my-durable-topi >c-subscription.html
They *should* be persistent, but I'll go back and make sure. > > Tom Corbin wrote: > > 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.
