2009/1/20 Rajith Attapattu <[email protected]>: > During testing I noticed the following. I would appreciate if folks who are > interested in this area comment about these observations. > > a) If a single broker is defined in the URL, by default FailoverSingleServer > is chosen. > In this case, I believe we should default to no failover unless explicitly > specified.
This is due to the historic merging of retry and failover. So SingleServerFailover is not really failover as it doesn't 'Failover' to anywhere it is simply a retry mechanism. Which I think most users would prefer. know that is how most of the users I deal would prefere the default of automatically reconnecting. There is still work to be done here as retrying or failing over after a certain set of exceptions makes no sense, Authentication Exception being the most obvious. If the password was wrong once retrying it isn't going to make it work. :) > b) The FailoverSingleServer method retries immediately upon a connection > error. > A connection error maybe due the broker crashing or due to a temp > network error. > In either case, IMO there is little value in retrying immediately. It > would be best to retry after a delay. > Rob pointed out that in the case of a fast dns switch this may come in > handy, but in other cases I believe a configurable timeout would be better. There is a 'connectdelay' property you can specify on a broker url to prevent immediate retry. It is documented on the Connection URL page: http://cwiki.apache.org/confluence/display/qpid/Connection+URL+Format There is also a 'connecttimeout' value that is configurable if you believe the network is going to be a bit ropey. > c) The actual number of retries == the no of retries configured + 1. > Is there a reason for this logic? This is just a bug but it may be due to the historic merging of retry and failover or a limitation of the failover desgin. So what is actually happening is that when then connection fails we always retry and establish connection to the dropped broker assuming a transient networking issue has caused the problem. If that fails then we start failing over and the specified retry values for failover are used. Hence the number of 'retries' you are seeing. Hope that is helpful. Martin > Thoughts/comments are greatly appreciated. > > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
