So 15 seconds sounds really low, although I'm not sure of all the various timeout settings in NFS.
Specifically here, the timeout of concern is the release of a lock held by a client. The higher the timeout, the less likelihood of two clients obtaining the same lock, but the slower failover becomes because of the added time to detect that the lock-holder is out-of-service. On the other hand, the lower the timeout, the greater the chances of two clients getting the same lock, but the faster failover becomes. I tend toward wanting reliability first, and fast recovery time second. Although that really depends on the use-case. However, for use-cases that require very fast recovery, I would look to non-persistent messaging, eliminating the issue of storage locking, but then requiring an alternate approach to handling potential message loss. The timeout here is one that must be handled by the server - whether the server allows different clients to request different timeout values, I don't know - but it's the NFS server that must apply it, because it needs to take effect when the client drops off the network unexpectedly. Hope this helps. BTW - if the two-active-broker scenario happens very commonly and the network appears to be performing well, then I would look to the possibility of the lock file getting removed somehow during startup. -- View this message in context: http://activemq.2283324.n4.nabble.com/question-for-users-of-NFS-master-slave-setups-tp4708204p4708776.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
