In This Section
Overview
Talon provides built in discovery providers that are used to simplify configuration and make the overall system less tightly coupled. Talon discovery is used for the following:
- Application cluster establishment (store discovery). To achieve High Availability you will typically launch 2 or more instances of your application which discovery one another to form an HA Cluster based on the application name.
- XVM discovery
- Allows management clients such as Robin and Lumino to discover running XVMs and their applications.
- Allows application's using the direct message bus binding implementation to find peer applications and connect to them.
Discovery Caches and Advertisements
A discovery provider provides the ability to load a discovery cache. A discovery cache allows its creator to advertise entities it owns by periodically broadcasting Entity State Advertisements (ESAs) to remote caches. Applications can register discovery event handlers with the cache to receive updates aboute newly added entities on remote caches or entities removed either explicitly by the remote cache or by virtue of stale entities "aging out" when ESAs are not received for an entity after some time.
Entity State Advertisements
Advertisements use an internal binary protocol and communicate the following information for each entity. A discovery cache will periodically broadcast ESAs to prevent remote caches for declaring them dead.
| Field | Description |
|---|---|
| Entity Owner | The unique id of the discovery cache that advertised the entity |
| Entity Type | The type of entity. Talon uses:
|
| Entity Name | The unique name of the entity being advertised. |
| Entity Instance | The unique instance identifier for the entity. For example an ODS Store Member would have the same name in each XVM for the same application, but would have uniquely identifiable instance id. |
| Entity Host | The host from which the entity was advertised. |
| Entity Address Descriptors | Each entity added to the cache includes a list of adress descriptors that contain connection information that can be used by |
| Entity Age | Get an entity's current age. See |
| Entity Max Age | Each entity instance is associated with a maximum age and, at any point in time, a current age. A cache member 'expires' (removes from its local cache) a discovered entity when its current age reaches its maximum age. To prevent entity expiry, member owners periodically broadcast ESA (Entity State Advertisement) packets. The receipt of a ESA by non-owner causes the entity's age to be reset. An entity's maximum age is also used (in conjunction with other configurable parameters) by owner members to determine when to send ESAs. |
Configuring Discovery
A discover cache is specified as a descriptor string of the form <provider>://<address>[&prop1=value]...[propN=valueN]. All discovery cache implementation support the following basic properties described below.
| Property | Default | Description |
|---|---|---|
| initWaitTime | 5 | Time (in seconds) to wait after sending the solicit packets for entities to join Upon construction, cache members solicit entity advertisements from remote members to populate its 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. The default value for this parameter is 5 seconds. It can be changed via the initWaitTime property in the cache descriptor e.g. mcast:224.0.1.200:4090&initWaitTime=10 would increase the initial wait time to 10 seconds. |
| 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. See The default value for this parameter is 30 seconds. It can be changed via the maxEntityAge property in the cache descriptor. For example, mcast:224.0.1.200:4090&maxEntityAge=20 would decrease the an entity's maximum age to 20. This parameter works hand in hand with the maxEsaLoss parameter. The cache uses both these parameters to determine how often to transmit ESAs. |
| maxEsaLoss | 6 | Number of ESAs if lost would cause an entity to be expired i.e. num ESA to advertise within the maxEntityAge interval A cache member manages the lifecyle of discovered entities via its maximum age. The member uses a timer to periodically increment the entity's age. When the age reaches the maximum age, it is considered expired and removed from the cache. Entity owners preempt expiry of an entity by continually broadcasting ESAs for the entity. The ESAs cause the entity's age to be reset in the remote caches. An entity owner determines how often to broadcast ESAs using the maxEntityAge and maxESALoss parameters i.e. ESAs are broadcast every maxEntityAge / maxESALoss seconds. The default value for this parameter is 6. It can be changed via the maxEsaLoss property in the cache descriptor. For example, mcast:224.0.1.200:4090&maxEsaLoss=10 would increase the ESA loss tolerance to 10. |
| memberName | 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, the user can override the use of UUIDs for identification through the use of the memberName property in the cache descriptor. For example, mcast:224.0.1.200:4090&memberName=m1 would identify the cache member opening a cache using the above descriptor as 'm1'. |
The Default Discovery Cache
Talon broadcasts Applications, Servers (aka 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 use ip multicast and defaults to "mcast://224.0.1.200:4090" This can be changed by configuring the environment property nv.discovery.descriptor:
Configuring Separate Server and Cluster Discovery
Using the default discovery provider for both server and cluster discovery is sufficient for most applications. However, there may be cases where it is advantageous to use separate providers.
Discovery Providers
This section lists the discovery providers that are available out of the box with talon.
Multicast
Multicast is the default discovery provider used out of the box ... it is set to mcast://224.0.1.200:4090
| Property | Default | Description |
|---|---|---|
| localIfAddr | N/A | When running on a host with multiple network interfaces that support multicast, this property can be used to specify the interface that should be used for discovery.
|
If you are on the same network as several of your peers and you are all working on the same application, it would be a good idea to choose your own port for discovery to avoid clashing.
SMA
The SMA discovery provider uses topic broadcasts for advertising packets. Any broker based SMA messaging provider can be used for discovery. The bus binding used for discovery will use the memberName as the value passed to the bus binding providers create method. Any bus binding specific properties can be passed in with the discovery descriptor. In addition to the bus binding properties, the SMA discovery providers allow configuration of the channel to use for discovery:
| Property | Default | Description |
|---|---|---|
| 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. |
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 server discovery to discover the hosts that they manage since a failure in the messaging fabric would also leave applications in a state where they aren't discoverable.
Example SMA discovery descriptors
| Provider | |
|---|---|
| solace | When using the solace provider, consider using the single_session=true property to reduce the number of thread created by the solace binding. The solace bindings created by the SMA discovery provider are marked as administrative and as such platform auto tuning will not result in busy spinning threads. |
| loopback | The loopback provider uses the loopback bus and can be used for disovery 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 would use jndi: |
| activemq |
Local
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. The local discovery provider can be particularly useful when writing unit tests that are launching all applications in the same jvm.