Events
This page describes different event types, when and where they are generated, and how you can use them.
You can always find the most complete and up to date list of events in the javadocs: Ignite events and GridGain Enterprise events.
General Information
All events implement the Event
interface.
You may want to cast each event to the specific class to get extended information about the action the event was triggered by.
For example, the 'cache update' action triggers an event that is an instance of the CacheEvent
class, which contains the information about the data that was modified, the ID of the subject that triggered the event, etc.
All events contain information about the node where the event was generated.
For example, when you execute an IgniteClosure
job, the EVT_JOB_STARTED
and EVT_JOB_FINISHED
events contain the information about the node where the closure was executed.
IgniteEvents events = ignite.events();
UUID uuid = events.remoteListen(new IgniteBiPredicate<UUID, JobEvent>() {
@Override
public boolean apply(UUID uuid, JobEvent e) {
System.out.println("nodeID = " + e.node().id() + ", addresses=" + e.node().addresses());
return true; //continue listening
}
}, null, EventType.EVT_JOB_FINISHED);
SubjectID
Some events contain the subjectID
field, which represents the ID of the entity that initiated the action:
-
When the action is initiated by a server or client node, the
subjectID
is the ID of that node. -
When the action is done by a thin client, JDBC/ODBC/REST client, the
subjectID
is generated when the client connects to the cluster and remains the same as long as the client is connected to the cluster.
Check the specific event class to learn if the subjectID
field is present.
If you use GridGain Enterprise or Ultimate edition and enable authentication, subjectID
allows you to get the user name that the node or client used to connect to the cluster.
This capability can be used for auditing purposes.
Cluster Activation Events
Cluster activation events are instances of the ClusterActivationEvent class. Cluster activation events are generated when the cluster is activated or deactivated. They contain the list of baseline nodes at the moment of the event.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_CLUSTER_ACTIVATED |
The cluster is activated (including when auto-activated). |
All cluster nodes. |
EVT_CLUSTER_DEACTIVATED |
The cluster is deactivated. |
All cluster nodes. |
Cache Lifecycle Events
Cache Lifecycle events are instances of the CacheEvent class. Each cache lifecycle event is associated with a specific cache and has a field that contains the name of the cache.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_CACHE_STARTED |
A cache is started on a specific node. Each server node holds an internal instance of a cache. This event is fired when the instance is created, which includes the following actions:
|
All nodes where the cache is started. |
EVT_CACHE_STOPPED |
This event happens when a cache is stopped, which includes the following actions:
|
All nodes where the cache is stopped. |
EVT_CACHE_NODES_LEFT |
All nodes that host a specific cache have left the cluster. This can happen when a cache is deployed on a subset of server nodes or when all server nodes leave the cluster and only client nodes remain. |
All remaining nodes. |
Cache Events
Cache events are instances of the CacheEvent class and represent the operations on cache objects, such as 'get', 'put', 'remove', 'lock', etc.
Each event contains the information about the cache, the key that is accessed by the operation, the value before and after the operation (if applicable), etc.
Cache events are also generated when you use DML commands.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_CACHE_OBJECT_PUT |
An object is put to a cache. This event is fired for every invocation of |
The primary and backup nodes for the entry. |
EVT_CACHE_OBJECT_READ |
An object is read from a cache. This event is not emitted when you use scan queries (use Cache Query Events to monitor scan queries). |
The node where read operation is executed. It can be either the primary or backup node (the latter case is only possible when reading from backups is enabled). In transactional caches, the event can be generated on both the primary and backup nodes depending on the concurrency and isolation levels. |
EVT_CACHE_OBJECT_REMOVED |
An object is removed from a cache. |
The primary and backup nodes for the entry. |
EVT_CACHE_OBJECT_LOCKED |
A lock is acquired on a specific key. Locks can be acquired only on keys in transactional caches. User actions that acquire a lock include the following cases:
|
The primary or/and backup nodes for the entry depending on the concurrency and isolation levels. |
EVT_CACHE_OBJECT_UNLOCKED |
A lock on a key is released. |
The primary node for the entry. |
EVT_CACHE_OBJECT_EXPIRED |
The event is fired when a cache entry expires. This happens only if an expiry policy is configured. |
The primary and backup nodes for the entry. |
EVT_CACHE_ENTRY_CREATED |
This event is triggered when GridGain creates an internal entry for working with a specific object from a cache. We don’t recommend using this event. If you want to monitor cache put operations, the |
The primary and backup nodes for the entry. |
EVT_CACHE_ENTRY_DESTROYED |
This event is triggered when GridGain destroys an internal entry that was created for working with a specific object from a cache.
We don’t recommend using it.
Destroying the internal entry does not remove any data from the cache.
If you want to monitor cache remove operations, use the |
The primary and backup nodes for the entry. |
Cache Query Events
There are two types of events that are related to cache queries:
-
Cache query object read events, which are instances of the CacheQueryReadEvent class.
-
Cache query executed events, which are instances of the CacheQueryExecutedEvent class.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_CACHE_QUERY_OBJECT_READ |
An object is read as part of a query execution. This event is generated for every object that matches the query filter. |
The primary node of the object that is read. |
EVT_CACHE_QUERY_EXECUTED |
This event is generated when a query is executed. |
All server nodes that host the cache. |
Class and Task Deployment Events
Deployment events are instances of the DeploymentEvent class.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_CLASS_DEPLOYED |
A class (non-task) is deployed on a specific node. |
The node where the class is deployed. |
EVT_CLASS_UNDEPLOYED |
A class is undeployed. |
The node where the class is undeployed. |
EVT_CLASS_DEPLOY_FAILED |
Class deployment failed. |
The node where the class is to be deployed. |
EVT_TASK_DEPLOYED |
A task class is deployed on a specific node. |
The node where the class is deployed. |
EVT_TASK_UNDEPLOYED |
A task class is undeployed on a specific node. |
The node where the class is undeployed. |
EVT_TASK_DEPLOY_FAILED |
Class deployment failed. |
The node where the class is to be deployed. |
Discovery Events
Discovery events occur when nodes (both servers and clients) join or leave the cluster, including cases when nodes leave due to a failure.
Discovery events are instances of the DiscoveryEvent class.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_NODE_JOINED |
A node joins the cluster. |
All nodes in the cluster (other than the one that joined). |
EVT_NODE_LEFT |
A node leaves the cluster. |
All remaining nodes in the cluster. |
EVT_NODE_FAILED |
The cluster detects that a node left the cluster in a non-graceful way. |
All remaining nodes in the cluster. |
EVT_NODE_SEGMENTED |
This happens on a node that decides that it was segmented. |
The node that is segmented. |
EVT_CLIENT_NODE_DISCONNECTED |
A client node loses connection to the cluster. |
The client node that disconnected from the cluster. |
EVT_CLIENT_NODE_RECONNECTED |
A client node reconnects to the cluster. |
The client node that reconnected to the cluster. |
Task Execution Events
Task execution events are associated with different stages of task execution. They are also generated when you execute simple closures because internally a closure is treated as a task that produces a single job.
Task Execution events are instances of the TaskEvent class.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_TASK_STARTED |
A task is started. |
The node that initiates the task. |
EVT_TASK_REDUCED |
This event represents the 'reduce' stage of the task execution flow. |
The node where the task was started. |
EVT_TASK_FINISHED |
The execution of the task finishes. |
The node where the task was started. |
EVT_TASK_FAILED |
The task failed |
The node where the task was started. |
EVT_TASK_TIMEDOUT |
The execution of the task timed out. This can happen when |
The node where the task was started. |
EVT_TASK_SESSION_ATTR_SET |
A job sets an attribute in the session. |
The node where the job is executed. |
Job Execution events are instances of the JobEvent class. The job execution events are generated at different stages of job execution and are associated with particular instances of the job. The event contains information about the task that produced the job (task name, task class, etc.).
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_JOB_MAPPED |
A job is mapped to a specific node. Mapping happens on the node where the task is started. This event is generated for every job produced in the "map" stage. |
The node that started the task. |
EVT_JOB_QUEUED |
The job is added to the queue on the node to which it was mapped. |
The node where the job is scheduled for execution. |
EVT_JOB_STARTED |
Execution of the job started. |
The node where the job is executed. |
EVT_JOB_FINISHED |
Execution of the job finished. This also includes cases when the job is cancelled. |
The node where the job is executed. |
EVT_JOB_RESULTED |
The job returned a result to the node from which it was sent. |
The node where the task was started. |
EVT_JOB_FAILED |
Execution of a job fails. If the job failover strategy is configured (default), this event is accompanied by the |
The node where the job is executed. |
EVT_JOB_FAILED_OVER |
The job was failed over to another node. |
The node that started the task. |
EVT_JOB_TIMEDOUT |
The job timed out. |
|
EVT_JOB_REJECTED |
The job is rejected. The job can be rejected if a collision spi is configured. |
The node where the job is rejected. |
EVT_JOB_CANCELLED |
The job was cancelled. |
The node where the job is being executed. |
Cache Rebalancing Events
Cache Rebalancing events (all except for EVT_CACHE_REBALANCE_OBJECT_LOADED
and EVT_CACHE_REBALANCE_OBJECT_UNLOADED
) are instances of the CacheRebalancingEvent class.
Rebalancing occurs on a per cache basis; therefore, each rebalancing event corresponds to a specific cache. The event contains the name of the cache.
The process of moving a single cache partition from Node A to Node B consists of the following steps:
-
Node A supplies a partition (REBALANCE_PART_SUPPLIED). The objects from the partition start to move to node B.
-
Node B receives the partition data (REBALANCE_PART_LOADED).
-
Node A removes the partition from its storage (REBALANCE_PART_UNLOADED).
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_CACHE_REBALANCE_STARTED |
The rebalancing of a cache starts. |
All nodes that host the cache. |
EVT_CACHE_REBALANCE_STOPPED |
The rebalancing of a cache stops. |
All nodes that host the cache. |
EVT_CACHE_REBALANCE_PART_LOADED |
A cache’s partition is loaded on the new node. This event is fired for every partition that participates in the cache rebalancing. |
The node where the partition is loaded. |
EVT_CACHE_REBALANCE_PART_UNLOADED |
A cache’s partition is removed from the node after it has been loaded to its new destination. |
The node where the partition was held before the rebalancing process started. |
EVT_CACHE_REBALANCE_OBJECT_LOADED |
An object is moved to a new node as part of cache rebalancing. |
The node where the object is loaded. |
EVT_CACHE_REBALANCE_OBJECT_UNLOADED |
An object is removed from a node after it has been moved to a new node. |
The node from which the object is removed. |
EVT_CACHE_REBALANCE_PART_DATA_LOST |
A partition that is to be rebalanced is lost, for example, due to a node failure. |
|
EVT_CACHE_REBALANCE_PART_SUPPLIED |
A node supplies a cache partition as part of the rebalancing process. |
The node that owns the partition. |
Transaction Events
Transaction events are instances of the TransactionStateChangedEvent class.
They allow you to get notification about different stages of transaction execution. Each event contains the Transaction
object this event is associated with.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_TX_STARTED |
A transaction is started. Note that in transactional caches, each atomic operation executed outside a transaction is considered a transaction with a single operation. |
The node where the transaction was started. |
EVT_TX_COMMITTED |
A transaction is committed. |
The node where the transaction was started. |
EVT_TX_ROLLED_BACK |
A transaction is rolled back. |
The node where the transaction was executed. |
EVT_TX_SUSPENDED |
A transaction is suspended. |
The node where the transaction was started. |
EVT_TX_RESUMED |
A transaction is resumed. |
The node where the transaction was started. |
License Events
License events are instances of the LicenseEvent class.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_LIC_CLEARED |
This event is generated when license violation has been removed. |
All cluster nodes. |
EVT_LIC_VIOLATION |
License restrictions are violated. |
All cluster nodes. |
EVT_LIC_GRACE_EXPIRED |
The grace period is coming to an end. |
All cluster nodes. |
Authentication Events
Authentication events are generated when a user tries to connect to the cluster protected by authentication. There are two types of authentication events, each type indicating whether the user was authenticated successfully or not.
Authentication events are instances of the AuthenticationEvent class.
Each event contains the type of the user (AuthenticationEvent.subjectType()
), which can be either a remote node or a remote client, and the user name that was used to log in.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_AUTHENTICATION_SUCCEEDED |
A user is successfully authenticated in the cluster. |
The node to which the entity is connected and where the authentication happened. |
EVT_AUTHENTICATION_FAILED |
User authentication failed. |
The node where the authentication happened. |
Authorization Events
Authorization events represent authorization checks preformed when a user tries to execute an operation. The check either succeeds or fails.
Authorization events are instances of the AuthorizationEvent class.
Each event contains information about the user and the operation that was performed (AuthorizationEvent.operation()
).
Refer to the authorization and permissions page for the list of operations that could require authorization.
Event Type | Event Description | Where Event Is Fired |
---|---|---|
EVT_AUTHORIZATION_SUCCEEDED |
A user is successfully authorized to execute an operation. The event contains the type of operation. |
The node where the operation is performed. |
EVT_AUTHORIZATION_FAILED |
A user is denied permission to execute an operation. |
The node where the operation is attempted. |
Data Replication Events
Refer to the Data Replication documentation.
© 2024 GridGain Systems, Inc. All Rights Reserved. Privacy Policy | Legal Notices. GridGain® is a registered trademark of GridGain Systems, Inc.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.