Hi Joe, Thanks again for your reply. Do you know when 5.3 is going to be released?
-Farshad Joe Fernandez wrote: > > Hi Farshad, > > You may have encountered the following problem: > http://issues.apache.org/activemq/browse/AMQ-2135 > > It is a rather nasty problem where messages become stuck in one of the > NoB's brokers. That is, a broker does not forward the messages to other > brokers in the NoB that have valid subscriptions. > > Not until you connect a consumer to one of the brokers that houses the > stuck messages, will the broker dispatch the message to the consumer. It > has to do with subscription management. > > There is this patch that addresses the problem, but only for > 'fully-connected' NoB topologies. > > http://issues.apache.org/activemq/secure/attachment/17800/AMQ-2135-Patch-03182009.patch > > If you're using a ring or line topology, the patch won't work and may make > matters worse. > > You may also encounter a situation where some of the brokers’ transport > threads are parked (stuck) on a Java CountDownLatch object and are thus > unable to service their respective transport. A transport in this case is > used to connect two brokers and the message broker assigns a worker thread > to service that transport. When this occurs, the NoB is compromised. Here > are some relevant links for this problem. > > http://www.nabble.com/Network-connector-failover-problems-td10224971.html#a10275742 > http://issues.apache.org/activemq/browse/AMQ-1827 > > Our testing indicated that the above 'parked thread' problem only occurs > with the failover connector. We were never able to reproduce it with the > static connector. > > I would also recommend moving to 5.3 when possible. > > Joe > http://www.ttmsolutions.com > > > farshad wrote: >> >> Hi Joe, >> >> Thank you for your reply. So, I set dynamicOnly to "true" and networkTTL >> to 4. The sender code puts messages in the queue and the receiver code >> connects and sometimes it gets all the messages and somtimes it gets some >> of them. I have to reconnect to get the rest of them. Also, if I shut >> down the broker that the messages were sent thru, no messages can be >> received. In my activemq.xml I have one broker definition and then copy >> the same config file into the all broker machines. Should each broker >> have its own unique broker definition? What is the use of >> staticallyIncludedQuues? >> >> Here's my config file: >> >> <destinations> >> <queue physicalName="Document.QUEUE" /> >> </destinations> >> >> <networkConnector name="myHosts" >> uri="static://(tcp://host1:61616,tcp://host2:61616,tcp://host3:61616,tcp://host4:61616)"> >> networkTTL=4 >> dynamicOnly=true >> </networkConnector> >> >> <transportConnectors> >> <transportConnector name="openwire" uri="tcp://localhost:61616" >> discoveryUri="multicast://default"/> >> </transportConnectors> >> >> Thank you, >> FarshadK >> >> >> Joe Fernandez wrote: >>> >>> You should use the static and not failover connector to configure your >>> network of brokers. Also make sure that you have the appropriate values >>> assigned to the networkTTL and dynamicOnly parameters. >>> >>> http://activemq.apache.org/networks-of-brokers.html >>> >>> Joe >>> http://www.ttmsolutions.com >>> >>> >>> >>> farshad wrote: >>>> >>>> I have a network of 4 brokers configuration with >>>> failover://(tcp://host1:61616,tcp://host2:61616,...) defined. My first >>>> piece of java code connects to one of these hosts (randomly) and puts >>>> some messages in a queue destination (e.g. Document.QUEUE). A second >>>> piece of java code connects to another one of these hosts and fails to >>>> read the messages. Is this expected behaviour? If I connect to one >>>> host and put messages in a queue and the host goes down what do I have >>>> to do to receive my messages connecting to another host in the network? >>>> >>>> Thank you in advance, >>>> FarshadK >>>> >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Question-about-Queue-destinations-in-network-of-brokers-tp25776018p25779532.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.