JobNode

JobNode listens to an input XQueue for JMS messages as the job requests. It classifies the incoming messages into groups based on the rulesets and the content of the messages. If an incoming message does not hit any ruleset, it will be routed to the bypass outlink at once. If the message hits a bypass ruleset, it will be routed to the bypass outlink. Otherwise, JobNode dispatches the incoming message to an available worker outlink based on the priority and the threshod of the group. If there is no enough worker available, the incoming message will be cached until the required worker resource is available. Meanwhile, JobNode periodically monitors all active jobs and sends query events to their worker outlinks. When the query events are collected, JobNode will escalate them to the first outlink, notice. Once a job has completed, JobNode will collect the request message from the worker outlink and cleans up the job.

JobNode contains multiple rulesets that categorize the incoming messages into non-overlapped groups. Each group has its own priority for scheduling and the threshold for the maximum number of active jobs. JobNode also supports the dynamic threshold via the list of ActiveTime. By default, all messages in the same group are unique. But if KeyTemplate is defined in the ruleset, messages with the same key are treated as identical. JobNode will make sure only the first one of the identical messages will be scheduled. This way, JobNode is able to manage and schedule jobs for each group of messages. A group can also define its own Heartbeat and DisplayMask, as well as the a bunch of property names. Hearbeat controls how often to query the status on active jobs. DisplayMask determines whether to log the escalation messages. Property names specify what properties to be copied over to the escalation messages.

JobNode always creates an extra ruleset, nohit, for those messages not hitting any pre-defined rulesets. For nohit, there is no flow control. The nohit messages will be routed to the outlink of bypass.

You are free to choose any names for the outlinks. But JobNode always assumes the first outlink for notice, the second for bypass, and the rest for workers.

Apart from the common properties, there are two implementation specific properties for JobNode.
Property Name Data Type Requirement Description Examples
Heartbeat integer optional interval in sec to dispatch 120
RCField string optional name of the field to store return code
where Heartbeat determines how frequently to check those active jobs. If StringProperty is defined on the node level, it will be used to build the summary on cached messages for display.

The schedule operation is executed via the pre-defined rulesets. Therefore, the configuration of the rulesets is critical to the operations of JobNode. Here are complete properties of rulesets for JobNode.
Property Name Data Type Requirement Description Examples
Name alphanumeric with no spaces mandatory name of the ruleset event
TimeToLive integer optional max number seconds for a job to be active 36000 (default: 0 for evergreen)
Heartbeat integer optional interval to check active jobs 300 (default is set by the node)
Priority integer optional prioeiry to schedule pending jobs 120 (default: 0)
Threshold integer optional max number of active jobs 4 (default: 1)
KeyTemplate string optional template for the unique keys of jobs ##AssetID##
KeySubstitution string optional text subsctitution for the unique key s/^0//
JMSPropertyGroup list optional list of pattern groups on properties to select messages see example
XJMSPropertyGroup list optional list of pattern groups on properties to exclude messages see example
PatternGroup list optional list of pattern groups on body to select messages see example
XPatternGroup list optional list of pattern groups on body to exclude messages see example
StringProperty map optional for copying properties of from the request messages to escalations see example
DisplayMask integer of 0 or 1 optional controling if to display the escalation messages 1 (default: 0)
where KeyTemplate is the template for unique jobs. If it is defined, the node will guarentee only one job running for any unique keys.

Here is an example of JobNode:

{
  "Name": "node_job",
  "ClassName": "org.qbroker.node.JobNode",
  "Operation": "schedule",
  "LinkName": "job",
  "Capacity": "512",
  "DisplayMask": "0",
  "Heartbeat": "30",
  "Debug": "5",
  "BufferSize": "8192",
  "StringProperty": {
    "method": "",
    "Duration": ""
  },
  "Ruleset": [{
    "Name": "express",
    "JMSPropertyGroup": [{
      "method": "^runJob$",
      "Duration": ["[,300]"]
    }],
    "Priority": "650",
    "Heartbeat": "120",
    "Threshold": "4",
    "KeyTemplat": "##method##:##Duration##",
    "DisplayMask": "1"
  },{
    "Name": "job",
    "JMSPropertyGroup": [{
      "method": "^runJob$",
      "Duration": "^\\d+$"
    }],
    "Priority": "450",
    "Heartbeat": "240",
    "Threshold": "2",
    "KeyTemplat": "##method##:##Duration##",
    "DisplayMask": "1"
  }],
  "OutLink": ["log", "done", {
    "Name": "script1",
    "Capacity": "32"
  },{
    "Name": "script2",
    "Capacity": "32"
  },{
    "Name": "script3",
    "Capacity": "32"
  },{
    "Name": "script4",
    "Capacity": "32"
  }]
}
where there are two rulesets with different hearteats.