Introduction

Feature List

Groups

Applications can easily become members of one or many user-defined groups. Groups allow applications to discover peers for scalability or high availability functions. Groups automatically elect 2 specially-designated members: "active" and "standby" (the application determines what these designations actually mean -- if anything). Members can indicate their capability to become "active" or "standby" and can specify a "credential" value -- the highest "credential" wins, allowing application programmers to guide the election process (if desired). Election results can be permanent or can be superceded by the admittance of a higher-credential member into the cluster (implementing optional fail-back semantics).

Applications can look at the member list of any group -- even ones they do not belong to. Groups can therefore be used to discover service providers. For example, the "load balancer" application can find all "web server" applications running in the cluster. Applications can also send messages to the "group" using different sending modes: the message can be directed to the active entity, the standby entity, all entities (broadcast), or a "random" entity (round-robin load balancing).

Groups make it easy to implement complex scale-out or high availability strategies, with no special logic inside the application.

Logging

Logs that are generated by applications are written to shared memory in an efficient, non-blocking manner. This means that logging's impact on the performance of your application is minimized and the last logs before an application crash are preserved even though the application may have crashed before the logs were flushed to disk. The SAFplus logging server (often embedded within the SAFplus AMF) reads logs from shared memory, filters them by "stream" and SYSLOG (RFC 5424) severity levels, and outputs them to any of:

• the file system (with max-size and log file rolling),
• the system syslog facility,
• any application (on any node) that has registered to receive that log stream.

A log "stream" is a cluster-wide, application defined portal for log messages. Logs originating anywhere in the cluster sent to a particular stream will be received by every subcriber of that stream.

Logging makes it easy for applications to send logs to a variety of destinations, with no special logic inside the application.