Discovery Model

Understanding how Talon microservices discover each other to form clusters and establish operational connections.

Overview

Talon provides built-in discovery mechanisms that simplify configuration and reduce coupling between components. Discovery enables:

• Application Cluster Establishment: Instances of the same application automatically discover each other to form an HA cluster based on the application name

• XVM Discovery: Allows administrative and monitoring tools to discover running XVMs and their applications

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 about 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 from 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: - "Application" for Talon applications - "OdsStoreMember" for Talon ODS stores - "Server" for XVMs
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 a 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 address descriptors that contain connection information
Entity Age	The entity's current age. See Entity Max Age for information on the role played by an entity's age in its lifecycle management
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 an 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

Discovery Cache Lifecycle

Discovery caches manage entity lifecycle through a combination of periodic advertisements and age-based expiration:

1. Entity Advertisement: When an entity is added to a cache, the cache begins periodically broadcasting ESAs for that entity

2. Age Management: Remote caches increment the age of discovered entities over time

3. Age Reset: When an ESA is received, the entity's age is reset to zero

4. Expiration: If no ESA is received before the entity reaches its maximum age, the entity is removed from remote caches

5. Event Notification: Applications can register handlers to be notified when entities are added or removed from the cache

Discovery Providers

Discovery providers implement different mechanisms for transmitting ESAs between caches. Talon includes several built-in providers to support different deployment scenarios.

Multicast

The multicast provider uses IP multicast for broadcasting ESAs. This is the default discovery provider.

Characteristics:

• Simple configuration with no infrastructure dependencies

• Well-suited for development and testing

• Limited to local network segment

• No central point of failure

Default Configuration:

• Default address: mcast://224.0.1.200:4090

Considerations:

• Must run over IPv4 stack (use -Djava.net.preferIPv4Stack=true on IPv6-preferring systems)

• Requires multicast-capable network

• On hosts with multiple network interfaces, you may need to specify which interface to use via the localIfAddr property

• On Mac OS X Yosemite and later, the virtual awdl0 interface can interfere with multicast discovery

SMA (Messaging-Based)

The SMA discovery provider uses topic broadcasts over any broker-based SMA messaging provider for advertising ESAs.

Characteristics:

• Works across network boundaries

• Leverages existing messaging infrastructure

• Supports distributed deployments

• Can be configured to use dedicated messaging infrastructure separate from application traffic

Configuration:

• Uses discoveryChannel property to specify the channel/topic name (default: _XEDP_)

• Supports all SMA bus bindings (Solace, JMS, ActiveMQ, Kafka, etc.)

• Bus binding-specific properties can be passed through the discovery descriptor

Tip: When using SMA-based discovery, consider using a different messaging server than the one used for application traffic, especially if monitoring tools rely on XVM discovery. A failure in the messaging fabric would otherwise leave applications undiscoverable.

Local

The local discovery provider is a simple provider for finding entities within the same process.

Characteristics:

• Lowest overhead

• In-process only

• No network communication

• Useful for unit testing and development

Use Cases:

• Unit tests launching multiple applications in the same JVM

• Development environments with collocated services

• Testing scenarios requiring isolated discovery

Discovery Usage Patterns

Default Discovery

By default, Talon uses a single global discovery cache for all discovery needs within a JVM. Applications, XVMs, and ODS Stores all advertise via this default cache, which uses multicast by default.

Separate Discovery Domains

In some scenarios, it's advantageous to use separate discovery providers for different purposes:

• XVM Discovery: Used by administrative and monitoring tools to find XVMs

• Cluster Discovery: Used by application instances to find peers and form HA clusters

Using separate discovery domains allows you to:

• Isolate administrative traffic from application cluster formation

• Use different network infrastructure for different discovery purposes

• Apply different discovery policies (timeout, max age) to different entity types

Design Rationale

Discovery in Talon is designed around several key principles:

Decoupling: Applications and tools don't need to know specific network addresses. They discover peers dynamically, allowing deployments to change without configuration updates.

Simplicity: The default multicast configuration requires no infrastructure setup, making development and testing straightforward.

Flexibility: Multiple provider options and the ability to configure separate discovery domains support diverse deployment requirements from single-developer environments to large distributed systems.

Resilience: Age-based expiration with periodic advertisements provides automatic cleanup of failed instances while tolerating temporary network issues through configurable ESA loss tolerance.

Configuration

Discovery is configured through DDL and environment properties. See:

• Discovery Configuration - Configuring discovery providers and descriptors

• Operating Model - How discovery integrates with administration and monitoring

Related Topics

• Cluster Join - How microservices use discovery to join clusters

• Operating Model - Discovery's role in administration and monitoring

• Admin Over SMA - Using SMA-based discovery for administration

Next Steps

1. Understand how discovery is used for cluster formation

2. Configure discovery for your environment in Discovery Configuration

3. Use the Discovery Tool to troubleshoot discovery issues