The Worker

The Worker

When an application (or program as we sometimes call it) is run in JADE, it launches what we affectionately call a Worker. A Worker’s interface shows the running statuses, plugin types, versions, instance names, etc. for all plugins.

It also provides us abilities such as:

  • shutting down and (re)running individual plugins
  • shutting down all plugins
  • rerunning the application plugins (whichever plugins were initially selected)
  • opening and closing plugin panels
  • opening a read-only editor which also display any run-time errors in the gutter
  • clearing plugin errors from the Worker view

Worker Published Data

The data published by a Worker includes status information about all running plugins. To subscribe to this data, simply use __PLUGIN_INFO__ in the subscribesTo array for any plugin which handles such data. Below is an example of the Worker’s __PLUGIN_INFO__ paylaod where the application consists of 3 plugins with instance names: “Serial Publisher 1”, “Serial Publisher 2”, and “My Subscriber”. The structure seen below is representative, where each plugin will have its info placed under a key name equal to its instance name.

 {
    "timestamp": 3753241024.79381,
    "workerName": "__PLUGIN_WORKER_41EBF6BD322192E917__",
    "pluginInfo": {
        "Serial Publisher 1": {
            "status": "Running",
            "type": "Serial Publisher",
            "version": "v1.1",
            "message": "The plugin instance is running."
        },
        "Serial Publisher 2": {
            "status": "Running",
            "type": "Serial Publisher",
            "version": "v1.1",
            "message": "The plugin instance is running."
        },
        "My Subscriber": {
            "status": "Running",
            "type": "Subscriber",
            "version": "v1.1",
            "message": "The plugin instance is running."
        }
    }
}

Worker Control Messages

The worker can also accept control messages from other plugins. For example, suppose we have a State Machine plugin in our system which is monitoring system data, and when a certain condition is met we are to run a specific plugin instance (which is in our program, but perhaps not set to run immediately, i.e. it was “unchecked” in the list). Well, all the State Machine would need to do in that case is send the correct message to the Worker. Below are examples of each message supported by Workers. Notice the common structure where all messages are JSON objects with elements: “operation” (string) and “data” (object).

Running a Plugin Instance

The following message sent to the Worker would run the plugin instance: “Serial Publisher 1”.

{
    "operation": "Instance Run",
    "data": {
        "InstanceName": "Serial Publisher 1"
    }
}

Shutting Down a Plugin Instance

The following message sent to the Worker would shut down the plugin instance: “Serial Publisher 1”.

{
    "operation": "Instance Shutdown",
    "data": {
        "InstanceName": "Serial Publisher 1"
    }
}

Shutting Down All Plugin Instances

The following message sent to the Worker would shut down all plugin instances.

{
    "operation": "Shutdown Instances",
    "data": {}
}

Opening a Plugin Instance Panel / Interface

The following message sent to the Worker would open the panel / interface associated instance: “Serial Publisher 1”.

{
    "operation": "Instance Show Front Panel",
    "data": {
        "InstanceName": "Serial Publisher 1"
    }
}

Hiding a Plugin Instance Panel / Interface

The following message sent to the Worker would close the panel / interface associated instance: “Serial Publisher 1”.

{
    "operation": "Instance Hide Front Panel",
    "data": {
        "InstanceName": "Serial Publisher 1"
    }
}

Shutting Down A Worker

The following message sent to the Worker would shut down the Worker, which would of course shut down all of the plugin instances running under that Worker’s domain. It would be unusual in most cases to do this since usually we want the Worker to remain available so we can control the application by sending it messages. Nonetheless, we expose it as there may be corner cases where it’s useful.

{
    "operation": "Close Application",
    "data": {}
}