For master-slave broker shared storage, ActiveMQ supports relational databases and a small number of shared filesystems. The range of filesystems is small because proper coordination requires a reliable and well-understood system of file locking, that responds usefully to such events as a the process holding the lock failing unexpectedly. At present, Red Hat tests and supports NFSv4 and, to a modest extent, GFS2 and CIFS.

In a fabric environment, Zookeeper provides master-slave coordination of brokers. Each broker instance registers a lock on an ephemeral ZK node, and this behaves in a similar way to a filesystem lock. It should therefore be possible to use ZK alone to coordinate master-slave operation. Filesystem locking would need to be turned off to avoid conflicts if the underlying locking was broken, but all the supported persistence adapters provide a way to do this.

However, although I have discussed this approach to locking with a number of people who take an interest in this kind of thing, and the consensus seems to be that it "should work," Red Hat currently has no testing for such a configuration, and it is therefore unsupported.

An ability to use filesystem-based master-slave storage with a shared filesystem that has inadequate or unspecified locking would be very helpful to customers who cannot control the filesystems in use. This is particularly the case for customers working in a cloud environment. For example Amazon ECS provides ObjectiveFS and SoftNAS, neither of which provide an NFS implementation with full NFSv4 locking semantics (Amazon EFS does claim to provide full NFSv4, but is only available in certain regions).

At present most customers running on Amazon cloud (and most likely other cloud hosts) have no way to run a master-slave broker configuration.

This is a request for Zookeeper-based master-slave broker operation, with filesystem locking turned off, to be added to our test plan so that it can be supported for customers.