For z/OS platforms

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>
Table 1. Default Values
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

Icon that indicates the type of topic Reference topic

File name: rwlp_wlmclassification.html