Summary: The status of clustered spaces can be viewed using different logging levels.
Overview The status of clustered spaces can be viewed using different logging levels. This status is managed by two threads - a Monitor and a Detector. The Monitor monitors the status of live spaces and reports disconnections, while the Detector detects the status of disconnected spaces and reports reconnection. The space status frequency can be configured using the CONFIG logging level. The com.gigaspaces.client.cluster.liveness logger is set by default (in gs_logging.properties) to INFO:
The different logging levels are detailed below:
Level |
Description |
CONFIG |
Displays default configurations and available configuration options for both Monitor and Detector threads. |
FINE |
In addition to the CONFIG level, displays disconnections logged by the Monitor and reconnections logged by the Detector. |
FINER |
In addition to the FINE level, displays disconnections logged by user operations and by the detector. |
FINEST |
In addition to the FINEST, displays reconnections logged by user operations and by the detector. |
Logging granularity and information assists in tracing the availability of cluster members when using load-balancing or failover policies. Examples
Configuration
System Property |
Description |
Default Value |
-Dcom.gs.cluster.livenessMonitorFrequency |
Defines the frequency in which liveness of 'live' members in a cluster is monitored. (Checks if available members become unavailable). |
10000 ms |
-Dcom.gs.cluster.livenessDetectorFrequency |
Defines the frequency in which liveness of members in a cluster is detected. (Detects if an unavailable member becomes available). |
5000 ms |
In most cases, livenessDetectorFrequency is the property you need to alter, since it is responsible for detecting spaces that are unavailable. The unavailability of cluster members is noticed when a direct operation is performed on them. The livenessMonitorFrequency property timely monitors all live cluster members. Usually, when you have backup-only spaces, this is most important. The only time an operation is performed on a backup-only space is when it becomes active (i.e., primary), and thus you want it's availability status to be noticed beforehand. It is recommended to increase the value of the Monitor thread to a maximum if there are many clients or if a large cluster is used. Usually, when there is no failover or when there are no backup-only spaces, the Monitor thread can be safely set to its maximum value, since clients directly interact with the space members. If either is detected as unavailable, the Detector thread is responsible for detecting whether they become available again. |