ActiveSpaces Concepts and Terminology

To configure TIBCO MDM with ActiveSpaces, you must understand the concepts and terminologies of the ActiveSpaces.

Agent

The amount of data that can be stored in a space depends on the number of seeding members of that space. It can be necessary to add seeders to a space to scale it up. AS-Agent is a prebuilt process that users can run on any host whose sole purpose is to join all distributed spaces in the specified metaspace as a seeder. Agents can also be used to ensure that the desired degree of replication specified for a space can be achieved.

Leech

A member that joins a space but does not lend any resources to the space, such as memory or processing power. Thus, plays a passive role.

Peer

A process that has connected to a metaspace and joined a space as either a seeder or a leech.

Metaspace

A metaspace is a logical concept representing two things:

  • From a deployment perspective, it represents the cluster of hosts and processes sharing the same metaspace name and set of multicast transport attributes, making a particular instance of an ActiveSpaces deployment. The hosts and processes in a metaspace can work together by joining the same tuple spaces.
  • From an administrative point of view, a metaspace is a container for a set of spaces. There are two kinds of spaces contained in a metaspace: system spaces, which are defined by ActiveSpaces itself, and user spaces, meaning spaces that are defined by a user.

A valid metaspace name must conform to the following rules:

  • Cannot start with a '$' or '_'
  • Can contain alphanumeric characters and '-' or '_'

The metaspace is the initial handle to ActiveSpaces. An application or member first joins a metaspace, and through it, gets access to other objects and functionality. For TIBCO MDM, the metaspace name is part of the configuration in the Configuration value under the name AS Meta Space Name. The default value is cim_ms.

Spaces

All records of a certain type are stored in a space. For TIBCO MDM, the spaces are identical to the caches. For each record type, there is a different cache. You can configure the caches in the CacheConfig.xml file.

Seeder

A member that joins a space and lends resources, such as memory and processing power, to the scalability of the space. Thus, plays an active role in maintaining the space by providing CPU and RAM.

In a distributed space, all peers are responsible for seeding certain tuples.

In a non-distributed space, one of the peers is assigned to be the seeder, determined by the ActiveSpaces distribution algorithm.

Ideally, peers are relatively stable, since there is overhead to reorganize the distribution of the tuples among the remaining peers when a peer leaves the space. For this reason, a transient application—one that will leave and join the space frequently—should generally be configured to join the space as a leech, rather than as a peer.

Agents are always seeders, not leeches. Agents provide an efficient, stable means of increasing the scalability of a space. Also, multiple seeders cannot be created from a single client program.

For each entry in a space, the ActiveSpaces distribution algorithm designates one seeder as the seeder of that tuple, whether or not the tuple is replicated on other members. The seeder holds and owns the authoritative copy of the complete tuple.

If the space has multiple seeders, a tuple may be held by different seeders at different times. If the current seeder of the entry leaves the space, another seeder is chosen as the entry’s new seeder, and the entry is then copied over to the new seeder.

Transport URLs

Transport arguments are specified in the form of URLs, one for the multicast transport and the other for unicast transport.

Multicast URL — com.tibco.cim.cache.as.multicasturl

Unicast URL — com.tibco.cim.cache.as.unicasturl

The multicast URL is a string specifying the arguments that is used by the multicast transport of ActiveSpaces to discover and communicate with the other members of the metaspace. All intended members of a metaspace must specify compatible multicast URLs in order for them to become members of the same metaspace.

The tibpgm:// and tcp:// URLs should be sufficient in most cases (single server and single subnetwork). The complete syntax is listed in the subsequent sections.

PGM (Pragmatic General Multicast) URL Format

The following multicast URL format means that the PGM multicast transport is used:

   tibpgm://[dport]/[interface]/[discovery IP multicast address]/[option=value;]*
  • [dport] specifies the destination port used by the PGM transport.
    Note: You must specify the unique port number in the Value attribute, else an error message is displayed. For example, 12345.
  • [interface]/[discovery IP multicast address] specifies the address of the interface to be used for sending multicast packets, and the multicast group address to be used. If not specified, the default interface and multicast address is used, that is, 239.8.8.8.
  • [option=value;] is a semicolon-separated list of optional PGM transport arguments. For example:
    • source_max_trans_rate=100000000 (in bits per second) confines the PGM transport to limit its transmission rate to 100 megabits per second.
    • By default, the PGM transport is tuned to provide the best performance according to the most common deployment architectures, and the values of those optional arguments should only be changed when necessary, and with care, as inappropriate values could easily result in degraded performance of the product.
      Tip: Creating raw PGM packets (as opposed to UDP-encapsulated PGM packets) requires the process to have root privileges on UNIX-based systems.

Unicast URL Format

To use a unicast URL, use a string of the following form:

   tcp://interface/port

This syntax indicates that the member should bind to the specified interface and the specified port when creating the TCP socket that will be used for direct communication between the members of the metaspace. If not specified, it will default to 0.0.0.0 (INADDR_ANY) for the interface and 0 (any free port) for the port.

A successful connection to the metaspace will return a valid instance of a Metaspace object, which can then be used to define, join, or leave spaces.

Unicast Discovery

If unicast discovery is enabled, every instance of ActiveSpaces tries to connect to a node in the discovery URL list in the order they are provided. Once connected to any of them, the node get information about “current manager” in the metaspace, and continue operations. If this node is not able to connect any member in the discovery URL list, the node indicates itself as a manager.

In Configurator, you can specify the discovery URL (com.tibco.cim.cache.as.discoveryurl) in the following format: IP-Address:port number.

Listen URL

By default, an ActiveSpaces instance listens on a random port in 30K+ range for ActiveSpaces internal data communication. If this range of ports are blocked, then provide an available port in Configurator (com.tibco.cim.cache.as.listenurl) in the following format: tcp://IP_address:port number.

To start an agent, use the following command:

as-agent.exe -metaspace="cim_ms" -discovery ""tcp://IP_A:7888"" where IP_A is the self IP of the local machine where you are starting agent.

In Configurator, add the following IP discovery address to detect the agent: IP_A:7888.

since two or more nodes share Configurator in a cluster, specify a port number for the listen URL, but not a specificIP address. For example,

Instead of

<ConfValue description="Provide the listen url for AS" name="AS Listen URL"       propname="com.tibco.cim.cache.as.listenurl" sinceVersion="8.2" visibility="Advanced">        <ConfString default="tcp://"  value="tcp://10.254.6.109:50001"/>   </ConfValue>

To

<ConfValue description="Provide the listen url for AS" name="AS Listen URL"       propname="com.tibco.cim.cache.as.listenurl" sinceVersion="8.2" visibility="Advanced">        <ConfString default="tcp://"  value="tcp://:50001"/>   </ConfValue>

In this example, port 50001 will be used on all nodes of the cluster.

Tuples

A tuple is similar to a row in the database table. Specifically, it is a sequence of named elements called fields (similar to the columns in a database table) which contain values of a specific type. Each tuple in a space represents a set of related data. Fields have a name and a type. A tuple can be seen as a kind of map on which fields can be put or removed.