The ingress and egress parts of a message’s journey therefore operate in separate Tcl contexts. The Tcl context contains the Tcl variables and execution state of the currently executing iRule event. Only one iRule event can execute at a time on a connection flow, therefore messages queue to execute their iRule events.
Generic messages may belong to independent transactions that are carried over the same network connection flow. It is highly desirable for messages sharing a connection flow to execute their iRules independently of other messages. This provides the following advantages and behavior changes:
- A message does not need to wait for an unrelated message to complete an event in order to execute its own event.
- Messages sharing a connection flow may exit the flow in a different order than they entered.
- Tcl variables cannot be overwritten between events by another message.
This capability may be enabled for genericmessage in the MR router profile via the irule-scope-message attribute. Before enabling irule-scope-message, the user’s iRules should be examined and if necessary adjusted and tested, to ensure they do not rely on sharing a Tcl context between messages on a connection flow.
- GENERICMESSAGE::message - returns or sets values in the message routing framework
- GENERICMESSAGE::peer - returns or sets the peer’s route name
- GENERICMESSAGE::route - add, delete, or lookup message routes
- GENERICMESSAGE_EGRESS - raised when a message is received from the proxy
- GENERICMESSAGE_INGRESS - raised when a message is received by the generic message filter
The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.