priority¶
Description¶
The priority command is used as an attribute associated with any iRule
event. When the iRules are loaded into the internal iRules engine for
a given virtual server, they are stored in a table with the event name
and a priority (with a default of 500).
Lower numbered priority events are evaluated before higher numbered
priority events: When an event is triggered, the irules engine passes
control to each of the code blocks for that given event in the order
of lowest to highest priority. Multiple events with the same priority
will be executed in the order they are inserted into the table.
The valid values for the priority are 0 to 1000 inclusive.
You can assign a priority between 1 and 1000 in one of two ways:
either with the priority command at the outermost scope of a rule, in
which case the designated priority is used for all subsequent events;
or as an additional argument to the when command, in which the
priority is only used for that event.
Syntax¶
priority nnn
when <event_name>
when <event_name> priority nnn
when <event_name> priority nnn¶
- used in conjuction with the event declaration. The value of nnn can be 0 to 1000 inclusive.
From unRuleY’s famous
post
on the topic: There are two factors that determine the order rules are
evaluated for the same event.
The first and most significant factor is the priority that has been
assigned to the event. All events default to a priority of 500.
You can assign a priority between 1 and 1000 in one of two ways:
either with the priority command at the outermost scope of a rule, in
which case the designated priority is used for all subsequent events;
or as an additional argument to the when command, in which the
priority is only used for that event. Lower numbered priority events
are evaluated before higher numbered priority events.
The second factor used in determining the order of evaluation is the
order in which the rule has been assigned to the virtual. For events
with the same priority, the rule that is listed first on the virtual
is evaluated first. This is likely difficult to determine and control
through the GUI, however it can easily be checked or changed with
bigpipe.
Examples¶
In this example, the first event is assigned priority 700 and both subsequent events are assigned priority 400. The second events will be evaluated before the other rules with a priority > 400.
rule my_test_rule {
priority 700
when HTTP_REQUEST {
HTTP::header insert ORIG_CLIENT_IP [IP::remote_addr]
}
priority 400
when CLIENT_ACCEPTED {
log "Client [IP::remote_addr] connected"
}
when HTTP_REQUEST {
log "Requested URI: [HTTP::host][HTTP::uri]"
}
}
In this example, one event is assigned priority 700, another is
defaulted to 500 and the third is 400:
rule my_test_rule {
when HTTP_REQUEST priority 700 {
HTTP::header insert ORIG_CLIENT_IP [IP::remote_addr]
}
when CLIENT_ACCEPTED priority 400 {
log "Client [IP::remote_addr] connected"
}
when HTTP_REQUEST {
log "Requested URI: [HTTP::host][HTTP::uri]"
}
}