Actually, maybe not, because I just realized that you're not actually changing your config. To confirm that, please disable the config refresh plugin and see if you still get the problem.
I think your problem is that you specified a networkConnector using failover without specifying maxReconnectAttempts=0. Fix that and see if your problem disappears. If not, is there any chance you're hitting the problem described in the "Stuck Messages" section of http://activemq.apache.org/networks-of-brokers.html? Please describe which broker each producer and each consumer are connected to before, during, and after you restart the broker that causes the problem. Tim On Mar 9, 2016 7:37 AM, "Tim Bain" <tb...@alumni.duke.edu> wrote: > It sounds like you've found a bug. Please submit a bug report in JIRA, > including config files and test steps required to reproduce the problem. > Please reduce the config files to the smallest form that still reproduces > the problem; eliminate anything that's not required, to make it easier for > whoever investigates the issue. > > Even better would be to create a unit test that demonstrates the problem > and attach that to the JIRA bug report. > On Mar 8, 2016 5:43 AM, "Lucas Dias" <lucas.d...@ceabs.com.br> wrote: > >> Hello, >> >> After many testing, it seems to work fine when reseting the broker. I've >> included a reboot step in my recipe to run when a broker comes up or down, >> indeed I've seen the network work again. >> >> It looks like the runtime plugin does not fully restores the broker >> network >> when reloading the file. >> >> Answering your question: When looking at the network consumers I see their >> number gets increased when there are messages being produced, however >> there's no consumption. >> >> The prefetch was just experimental, as you can read at the documentation: >> >> "If you have very few messages and each message takes a very long time to >> process you might want to set the prefetch value to 1 so that a consumer >> is >> given one message at a time." >> >> I was experimenting some values to find any evidence, my hipothesis was >> the >> network connections were holding messages as I've seen too many broker to >> broker consumers. >> >> The evidence seems towards the network is still not prepared for dynamic >> configurations. >> >> I will try a few more testing, and eventually come up with more evidences. >> >> Thank you >> >> >> >> -- >> View this message in context: >> http://activemq.2283324.n4.nabble.com/Queue-hanging-with-n-to-n-network-of-brokers-tp4707499p4709039.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> >
