-
Notifications
You must be signed in to change notification settings - Fork 3
Configuration
This page describes how to configure the gossip instance using YAML.
The configuration elements of the gossip instance consist of:
- The gossip parameters
- The list of gossip seeds
- The failure detection factory
All of the parameters controlling the gossip are optional and default to sensible defaults.
- cleanupCycles - the number of gossip cycles to wait until cleaning up a member marked as failed.
- commThreads: - the number of dispatch threads used to notify listeners of gossip events
- endpoint - the host and port (host:port) the gossip instance will listen on. Defaults to "*:0", which means it will bind to all interfaces and randomly choose a port to bind to.
- gossipInterval - the time between gossip cycles
- gossipUnit - the time unit of the gossip cycle
- heartbeatCycle - the number of gossip cycles before a heartbeat is sent
- hmac - the JCE algorithm name for the hmac used to authenticate and validate the gossip messages
- hmacKey - the key used for the hmac algorithm
- quarantineDelay - the number of milliseconds to delay before quarantining a failed member
- receiveBufferMultiplier - the number of buffers to allocate for receiving messages
- sendBufferMultiplier - the number of buffers to allocate for sending messages
- unreachableDelay - the number of milliseconds to delay before declaring a member unreachable
Note that you don't have to specify the host and port that the gossip instance binds to. The nature of gossip is that it is a discovery mechanism. Thus, you only need a few instances that have well known addresses. Seed members - i.e. the members used to establish the gossip network - will require explicit port configuration, but because you can bind to all addresses on the machine (Use "*" or simply leave the host field empty to bind to all addresses).
The nature of gossip requires at least one well known member address in order to work. There is no broadcast capabilities we can take advantage of for primitive discovery. Thus, every member must have at least one well known address that it can use to discover everyone else. These well known addresses do not have to be up - well, not unless you have only one that is.
The gossip seed list is simply a list of internet endpoints (host:port) elements.
Lastly, the failure detection factory configuration. This is probably the most complex aspect of the system, and one that I would not suggest you experiment a lot with. The configuration is polymorphic, and must resolve to a class that implements the FailureDetectorFactory interface.
Note that this is an optional configuration element, as the default factory is pretty darn good. You may, however, need to tweak this configuration with larger elements.
The failure detector factories are all POJOs that can be configured through the normal YAML conventions. The one property required, however, is "class". This is the fully qualified name of the failure detection factory implementation. For example, here's the YAML equivalent of the default factory configuration:
fdFactory:
class: com.hellblazer.gossip.fd.AdaptiveFailureDetectorFactory
convictionThreshold: 0.9
windowSize: 100
scale: 0.8
expectedSampleInterval: 20000
initialSamples: 10
minimumInterval: 3000
Please see the individual failure detection factory classes in the com.hellblazer.gossip.fd package for the properties they require for configuration.
cleanupCycles: 5
commThreads: 10
endpoint: :0
gossipInterval: 3
gossipUnit: SECONDS
heartbeatCycle: 2
hmac: HmacMD5
hmacKey: I0WDrSNGg60jRYOtI0WDrQ==
quarantineDelay: 30000
receiveBufferMultiplier: 6
sendBufferMultiplier: 5
unreachableDelay: 36000
seeds:
- localhost:666
- localhost:668
fdFactory:
class: com.hellblazer.gossip.fd.AdaptiveFailureDetectorFactory
convictionThreshold: 0.9
windowSize: 100
scale: 0.8
expectedSampleInterval: 20000
initialSamples: 10
minimumInterval: 3000