WLM classification for z/OS
Syntax and support notes about Liberty for z/OS® workload management (WLM) feature.
A WLM enclave is associated with the thread that the request is dispatched on. It is also
associated with a WLM Service Class. A WLM Service Class is assigned to the WLM enclave by WLM,
based on rules that you define in the WLM configuration. The WLM Service Class indicates the WLM
goals for each class of client work, for example, 95% complete in 1 second or less. The WLM Service
Class also indicates the importance of the goals relative to other work on the system. WLM uses
information that is provided by the Liberty
server during classification to assign a WLM Service Class. The following three properties help WLM
to classify the work:
- Subsystem Type
- For WebSphere®, Subsystem Type is CB.
- Collection Name
- Name of the server that is running the work. You can create WLM classification rules that are based on the server that is running the work.
- Transaction Class
- Name that is determined from classification of the work within Liberty code. Transaction Class is based on the Liberty configuration that you provide for the request that is being dispatched. You can assign different Transaction Classes to different applications within the same server, and thus different WLM Service Classes.
Syntax for configuration in the server.xml
file:
<featureManager>
<feature>zosWlm-1.0</feature>
</featureManager>
<wlmClassification>
<httpClassification transactionClass="CLASS001" host="127.0.0.1" port="9080" method="GET"
resource="/testResource" />
</wlmClassification>
Attributes | Default values |
---|---|
transactionClass="" | Empty string |
host="*" | Wildcard |
port="*" | Wildcard |
method="*" | Wildcard |
resource="*" | Wildcard |
Important:
- All attributes of <httpClassification ... /> are optional.
- If you turn on WLM, but do not specify a minimum of one rule, WLM is active but no enclaves are created.
- Classification rules have a top-down ordering, that is, each rule takes precedence over all rules below it.
- Transaction Classes can be mixed case.
- Ports can be specified as ranges. For example, port="9080-9085".
- Ports and methods can be specified as a comma-separated list. For example, port="9043,9080" or method="GET,PUT".
- Resources can be specified by using wildcards. One asterisk represents any number of characters,
and is used as a wildcard for the string between two path separator (/) characters. Two consecutive
asterisks represent any number of characters that include the path separator. Double asterisks
cannot appear with other characters within a pair of path separators.
- resource="/test*/*" matches /testaa/bb.html, but does not match /testaa/bb/cc.html
- resource="*.html" matches /aaa.html but does not match/aaa/bbb.html
- resource="/go/set*/**/archive.jsp" matches /go/seta/bb/2/archive.jsp, /go/setaa/bb/2/archive.jsp, and /go/set/archive.jsp
- The default, if resource= is not specified, matches ALL strings, which is equivalent to resource="/**/*", which matches /aaa, /aaa/bbb, and /aaa/bbb/ccc.html
Example
configuration:
<wlmClassification>
<httpClassification transactionClass="CLASS004" resource="/res2"/>
<httpClassification transactionClass="CLASS003" resource="/res1"/>
<httpClassification transactionClass="CLASS002" port="9043" />
<httpClassification transactionClass="CLASS001" />
</wlmClassification>
Notes:
- Rules 1 and 2 catch all incoming requests to their respective resources
- Rule 3 catches any incoming request not to either listed resource but on port 9043
- Rule 4 is a "catch-all" rule, which matches any request that comes in that was not matched by Rule 1, Rule 2, or Rule 3