Plugins Jobs


The development of a plugin is quite free in term of design and implementation choices but wxRaven provides a standardized approach for background tasks : jobs.

It is a common practice to use threads for background processing and for the most common and simple task this is the way to go.


Whenever you feel that a background task could be reused, shared or delegated to another server, here jobs become a relevant solution :


Jobs are a custom implementation for threading that allow the plugin to delegate the execution to a Job Manager in wxRaven.

Job manager works with multi-threading and will sequence and manage all the background activities requested by the HMI.





Jobs and usage scenarios


Jobs are useful for multiple reasons or scenarios :


    • Jobs manager is able to filter repeated request and proceed only one instance of the requested job
      Example : Overall GUI Layout refresh function can be called from multiple triggers and those can occur at the same time.
      In this case the job manager will detect, and delay the refresh in order to refresh only ONCE the layout and only after successive triggers.

    • Jobs produce a result data and those results can be reused within a defined expiration period, allowing to reuse jobs results and so improve the processing time.
      this can be used as a basic cache mechanism specially useful for the basic datas at open/closure of views or for some static datas that doesn't require to be updated from the blockchain as often.
      basic plugins informations may be loaded at the application startup using jobs allowing other plugins to retrieve those datas faster.

    • Jobs can be sequenced, ordered : huge analysis activities may require to execute or re-execute multiple time similar jobs, job manager include an ordering / condition mechanism to coordinate this.

    • Jobs can be serialized and so tasks can be executed remotely ! this is where jobs are shining too, considering a job a a succession of multiple many functions which include most of them RPC calls this can lead to some flooding issue when using remote connexions. With jobs, this simply cannot happen anymore since instead of sending 100 RPC calls successively, if the remote server allows it you can request the job to be executed directly their. this translate a 100 RPC calls between client server to a reduce amount : 1 for the request, few queries for progress report , 1 for the final result.

    • Jobs and specially for web-services can be implemented in two parts : a client-side and a server-side.


More details about jobs in the dedicated section.


Created with the Personal Edition of HelpNDoc: Single source CHM, PDF, DOC and HTML Help creation