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": {} }