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-topic-subscription.html 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. > > > -- View this message in context: http://www.nabble.com/Not-quite-sure-where-to-go-next---network-bridging%2C-reliable-delivery%2C-store-and-forward.-tp19764204p19781071.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
