The unique id of the discovery cache that advertised the entity

The type of entity.

Talon uses:

• "Application" for Talon applications
• "OdsStoreMember": for Talon ODS stores.
• "Server": for XVMs.

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.

Get an entity's current age.

See Entity Max Age for information on the role played by an entity's age in its lifecycle management

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. 

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. 

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 IDiscoveryEntity.getMaxAge for a description on the role played by an entity's age in its lifecycle management.

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. 

Number of ESAs, if lost, that would cause an entity to be expired i.e. num ESA to advertise within the maxEntityAge interval

A cache member manages the lifecycle 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. 

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'. 

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.

A common issue with multicast discovery occurs when 2 hosts bind to adapters that are different discovery networks.

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 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 autotuning will not result in busy spinning threads.

<env>
  <nv>
     <discovery>
       <descriptor>solace://solacehost:55555&amp;single_session=true</descriptor>
     </discovery>
  </nv> 
</env>

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.

<env>
  <nv>
     <discovery>
       <descriptor>loopback://server-discovery</descriptor>
     </discovery>
  </nv> 
</env>

Configuring a generic JMS discovery provider would use jndi:

<xvm>
  <discovery>
    <provider>jms</provider>
    <address>tibcohost</address>
    <port>27326</port>
    <properties>
	  <username>admin</username>
	  <password>changeme</password>
	  <jndi>true</jndi>
	  <jndi_contextfactory> com.tibco.tibjms.naming.TibjmsInitialContextFactory</jndi_contextfactory>
	  <jndi_principal>admin</jndi_principal>
	  <jndi_credentials>changeme</jndi_credentials>
	  <jndi_connectionfactory>CSTopicConnectionFactory</jndi_connectionfactory>
	  <maxEntityAge>150</maxEntityAge>
	  <maxEsaLoss>30</maxEsaLoss>
	  <discoveryChannel>=_XEDP_/dev</discoveryChannel>
    </properties>
  </discovery>
</xvm>