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

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 lifecyle 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 a 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 lifecyle 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 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 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 disovery 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>