Open topic with navigation

TIBCO ActiveSpaces® - Enterprise Edition 5.0.0

# Processes in ActiveSpaces

The following processes are involved in creating, maintaining, and querying the data grid:

- ActiveSpaces Client Applications
- Proxy
- Realm Service
- State Keeper
- Node
- Administration Service or Administration Daemon

TIBCO ActiveSpaces Client Applications
The client applications use the API libraries included with the product to build custom applications. Client applications interact with the data grid by using the proxy process.
Proxy
A proxy is a mediator between a client request and the data grid. Based on the client request, the proxy identifies the primary node in a copyset and interacts with the primary node until the request is processed and shared with the client. You can have many proxies in a data grid. You can configure a TIBCO FTL Server to run a proxy as a service, however, TIBCO recommends to run proxies as standalone instances.
Realm Service
A data grid is run inside a TIBCO FTL realm. A TIBCO FTL realm serves as a repository for data grid configuration information and provides communication services that enable all data grid processes to communicate with each other.
A client application accesses the data grid by using the realm service URL. In TIBCO FTL 6.0.0 or later, the realm service URL is the URL of the TIBCO FTL server. The realm service offers the following capabilities:

- Stores data grid definitions
- Communicates with the administrative tools to store and retrieve data grid definitions
- Communicates with all the processes running in the data grid and updates the internal configuration if anything changes
- Collects monitoring data from all processes

Fault Tolerance in Realm Services Used in TIBCO FTL 6.0.0 or Later

TIBCO FTL 6.1.0 or later uses a quorum-based fault tolerance mechanism. A cluster of at least three TIBCO FTL core servers must be run. Each core server provides a realm service. Those realm services all cooperate to provide fault tolerance for the data grid. Fault tolerance is assured as long as a quorum of servers is always running. Each core server must be run on a separate machine. Clients receive a list of URLs at which they can connect to those TIBCO FTL core servers.

State Keeper
A state keeper runs internally in the data grid and tracks all the data in the data grid. Each state keeper saves the data locally on the disk. When you start the realm service, the state keeper receives the data grid configuration information from the realm service.
You can either run standalone state keepers or you can configure TIBCO FTL servers to run them as services.
State keepers are responsible for the following functions:

- Tracking and managing all the copysets in a data grid
- Tracking the proxies in a data grid
- Identifying a primary node in each copyset
- Promoting one of the secondary nodes as primary, in case the primary node of a copyset goes down
- Ensuring consistency as the data grid scales up

Fault Tolerance in State Keepers
It is good practice to have three state keepers running in a production environment. A set of fault-tolerant state keeper processes protects the data grid's run time state information and ensures nonstop access to it. One of the state keepers is designated the lead state keeper and supplies this information to the proxies and copyset nodes. If the lead state keeper goes down, one of the secondary state keepers takes over as the lead. In a fault-tolerant set of three state keepers, a quorum of two state keepers must always be running to ensure data consistency in split brain scenarios. If a state keeper is restarted while a quorum is running, one of the running state keepers updates the state of the restarted state keeper. If the number of running state keepers falls below the quorum and the state of a copyset changes (for example, a node goes down), operations on the data grid fails. When this happens, the remaining state keepers must be brought down, and then all state keepers must be restarted.
Node
For more information on nodes, see the "Nodes" section in How Data is Stored in a Data Grid?
Fault Tolerance in Nodes
To prevent data loss, you can run up to three nodes per copyset. For production deployments, TIBCO recommends using at least two nodes per copyset.
Administration Daemon or Service
If there are clients running SQL DDL commands, you must run an administration daemon or service.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO ActiveSpaces® - Enterprise Edition

Copyright © 2009-2025. Cloud Software Group, Inc. All Rights Reserved.