5.270 Handling Events

Plugin events (excepting the poll event) are currently in Beta. Interfaces may change significantly in future releases.

Plugin types may handle specific events by containing methods defined by the conventions below. All events are optional.

The polling event

To maintain current information, each plugin is polled at a specified time interval. The following method definition is required to utilize the polling event.

void poll() { … }

Typically this polling method is used to report node and virtual machine information. By default, the polling interval is set to 30 seconds, but can be modified for all or individual plugins as explained in Plugin Management.

When a polling event occurs, the poll method on the target plugin is called. This method may perform any function desired and should typically make calls to the Node RM Service, the Virtual Machine RM Service, and the Job RM Service services to report the current state of nodes and virtual machines. For example, the poll method in the Native plugin type is implemented as follows:

This is an extremely simplified version of what is actually implemented in the Native plugin type.

INodeRMService nodeRMService;
IVirtualMachineRMService virtualMachineRMService;

public void poll() {
	nodeRMService.save(getNodes());
	virtualMachineRMService.save(getVirtualMachines());
}

This simple poll method calls two other helper methods called getNodes and getVirtualMachines to retrieve node and virtual machine reports. These reports are then sent to the appropriate RM service. See Reporting State Data for more information on the RM services; however, the objective of this example is to demonstrate one possible use of the poll event handler. Other plugin types, on the other hand, may use the poll event to update internal data from pertinent resources or make calls to external APIs.

Lifecycle events

Events are also triggered for certain lifecycle state changes. The following method definitions are required to receive lifecycle events.

public void configure() throws InvalidPluginConfigurationException { … }
public void beforeStart() { … }
public void afterStart() { … }
public void beforeStop() { … }
public void afterStop() { … }

Each event is described in the table below with the associated state change when the event is triggered.

Currently, no events are triggered for pausing, resuming, erroring, or clearing errors for plugins.

RM events

When MWS is configured as a Moab Resource Manager (see Moab Workload Manager Resource Manager Integration, and more specifically, Configuring Moab Workload Manager), RM events are sent from Moab to each plugin according to the routing specification (see Routing). The following method definitions are required to receive these events.

public boolean jobCancel(String jobName) { … }
public boolean jobModify(String jobName, Map<String, Object> attributes, ModifyMode modifyMode) { … }
public boolean jobRequeue(String jobName) { … }
public boolean jobResume(String jobName) { … }
public boolean jobStart(String jobName, List<String> nodes, String username) { … }
public boolean jobSubmit(Map<String, Object> job, String submissionString, String submissionFlags) { … }
public boolean jobSuspend(String jobName) { … }
public boolean nodeModify(List<String> nodes, Map<String, String> attributes, ModifyMode modifyMode) { … }
public boolean nodePower(List<String> nodes, NodeReportPower state) { … }
public boolean virtualMachinePower(List<String> virtualMachines, NodeReportPower state) { … }

Related Topics 

• Events
• Notifications
• Notification Conditions
• Plugin Developer's Guide
• Fields: Events
• Resources Introduction
• Plugin Event Service
• Creating Events and Notifications

© 2016 Adaptive Computing