1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
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.
|
