

Design of FILE_PING
===================

Author: Bela Ban


Goal
----

FILE_PING is a shared storage based discovery; during the discovery process,
new nodes read the addresses of existing members from a shared store.

Members write their addresses to the store and remove them on leaving the cluster.


Design
------

FILE_PING takes as property a 'location' which is the location of a directory in a shared store, e.g. /share/jgroups.
Each cluster X creates a subdirectory X, where all files for cluster X reside.

A member writes its local address (plus physical address mappings) to a file which is named after the local address.
Example: /share/jgroups/DemoCluster/linux-433234.dat. (Maybe we should use the UUID!)

A new member reads all files in DemoCluster and sends the discovery request to all addresses resulting from this.

When a member leaves, it removes its file from DemoCluster. We could use File.removeOnExit() to do this automatically.
(However, kill -9 doesn't remove the file).

We still need to periodically clean up members who crashed (kill -9). This could be done via an age out cache.


Notes
-----

In 2.6.x, we don't have logical addresses, therefore we don't need the discovery messages to ship logical-physical
address mappings around. As an optimization, we could read all files and see if we have an element tagged as
coordinator. If so, we could directly send a JOIN request to the coord, rather than sending discovery messages.
If there is no coordinator, we go through the regular discovery message sending process.
