Discovery Configuration
Configure discovery providers, cache properties, and separate discovery domains for XVM and cluster discovery.
Overview
Discovery caches are configured using descriptor strings that specify the provider, address, and additional properties. All discovery cache implementations support common properties for controlling entity lifecycle and advertisement behavior.
Discovery Descriptor Format
A discovery cache descriptor follows this format:
<provider>://<address>[&prop1=value]...[&propN=valueN]For example:
mcast://224.0.1.200:4090&initWaitTime=10&maxEntityAge=30Common Discovery Properties
The following properties are supported by all discovery cache implementations:
initWaitTime
5
Time (in seconds) to wait after sending solicit packets for entities to join. Upon construction, cache members solicit entity advertisements from remote members to populate the local cache. The initial wait time is the time that the cache constructor will sleep waiting for remote entities to be populated in the local cache.
maxEntityAge
30
Time (in seconds) that can elapse without receiving an ESA before an entity is deemed dead.
The maximum age associated with each entity created by the local cache member. This parameter works hand in hand with the maxEsaLoss parameter to determine how often to transmit ESAs.
maxEsaLoss
6
Number of ESAs, if lost, that would cause an entity to be expired (i.e., number of ESAs to advertise within the maxEntityAge interval).
An entity owner determines how often to broadcast ESAs using the maxEntityAge and maxESALoss parameters: ESAs are broadcast every maxEntityAge / maxESALoss seconds.
memberName
UUID
Each discovery cache member is uniquely identified by a name. The member name is used to identify entity ownership. By default, each member is uniquely identified by a UUID. However, you can override the use of UUIDs for identification through the use of the memberName property.
The Default Discovery Cache
Talon broadcasts Applications, XVMs, and ODS Stores via discovery. Unless configured otherwise, these will be done using the default (global) discovery cache singleton in the JVM.
The default discovery descriptor uses IP multicast and defaults to mcast://224.0.1.200:4090.
This can be changed by configuring the environment property nv.discovery.descriptor:
DDL Configuration:
System Property:
Configuring Separate XVM and Cluster Discovery
Using the default discovery provider for both XVM and cluster discovery is sufficient for most applications. However, there may be cases where it is advantageous to use separate providers.
Example: Using SMA for cluster discovery while using multicast for XVM discovery:
Provider-Specific Configuration
Multicast Discovery
The multicast provider is the default discovery mechanism.
Descriptor Format:
Multicast-Specific Properties:
localIfAddr
N/A
When running on a host with multiple network interfaces that support multicast, this property specifies the interface that should be used for discovery.
|
Example:
Use IPv4: Multicast should be run over an IPv4 stack. When running on an OS or JVM that prefers IPv6, you should explicitly specify the usage of IPv4 by setting -Djava.net.preferIPv4Stack=true
Mac OS X Yosemite or Later: The Yosemite OS X version and beyond create a virtual interface (awdl0) for Airplay that states it has multicast enabled, but multicast does not work if that interface is discovered by the multicast provider. There is a tool called WiFried that allows one to selectively disable this interface temporarily.
SMA Discovery
The SMA discovery provider uses topic broadcasts for advertising packets. Any broker-based SMA messaging provider can be used for discovery.
Descriptor Format:
SMA-Specific Properties:
discoveryChannel
XEDP
The channel name to create and use for discovery. Because message bus topics start with the channel name by default, this value is used as the topic name on the message bus.
Any bus binding-specific properties can be passed in with the discovery descriptor. The bus binding used for discovery will use the memberName as the value passed to the bus binding provider's create method.
Resilience Consideration: When considering using SMA-based discovery, you might want to consider using a different messaging server than the one used for application traffic, particularly if you will be using monitoring tools that rely on XVM discovery to discover the hosts that they manage. A failure in the messaging fabric would otherwise leave applications undiscoverable.
Example SMA Discovery Descriptors:
Solace:
When using the Solace provider, consider using the single_session=true property to reduce the number of threads created by the Solace binding. The Solace bindings created by the SMA discovery provider are marked as administrative and as such platform autotuning will not result in busy-spinning threads.
Loopback:
The loopback provider uses the loopback bus and can be used for discovery within the same process. It can be useful in testing scenarios to simulate a message-based discovery provider, but it is often more efficient to use the local discovery provider described below.
JMS:
Configuring a generic JMS discovery provider uses JNDI:
ActiveMQ:
Kafka:
Local Discovery
The local discovery provider is a simple provider that can be used to find other entities in the same process. It is similar to the SMA loopback provider but has lower overhead.
Descriptor Format:
Use Cases:
Unit tests launching all applications in the same JVM
Development with collocated applications
Testing scenarios requiring isolated discovery
Example:
Related Topics
Discovery Model - Understanding discovery concepts
Admin Over SMA - Administrative discovery configuration
Discovery Tool - Troubleshooting discovery
Next Steps
Choose appropriate discovery provider for your environment
Configure default discovery cache for XVM discovery
Optionally configure separate cluster discovery for applications
Test discovery configuration using the Discovery Tool
Monitor entity advertisements and age-out behavior
Last updated