This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
In the last couple of posts we’ve looked at how Liberty works with WLM to classify the work it is doing so WLM knows what is going on inside the server and can manage the server’s use of system resources (i.e. CPU) relative to other things running on the system to try to meet the defined goals for this work and everything else that’s running.
Last week we saw that to do that Liberty would provide to WLM a Transaction Class (TC) that would be used by WLM, in conjunction with classification rules defined in the WLM policy, to map the work being run to a service class (goal/importance) and a report class.
All that leaves us with the question of how Liberty knows what Transaction Class to specify.
First of all, what is a Transaction Class? It is just a string. There’s nothing special about it. It can be anything you want. You’ll specify it as part of a classification rule in the CB subsystem classification in your WLM policy. Your Transaction Class names should be eight or fewer characters.
How then does Liberty know what these 8-character strings are that you’ve put in your WLM policy classification rules? You tell the server as part of your server configuration. There’s a WLM classification configuration element and it will have sub-elements that tell the server what work maps to what Transaction Class name.
For HTTP work it is pretty easy. There’s an HTTP classification element that can specify a host name, a port number, and a URL. The URL is the most likely thing to classify by since it generally maps to the application. You can wildcard with an asterisk at the end, so you can just specify the context root for an application and an asterisk and any inbound HTTP request for anything in that application will match that element.
Each HTTP classification element also specifies a Transaction Class name. As each request is received its attributes are compared to the attributes of the HTTP classification elements in the order they appear inside the WLM classification element. As soon as a match is found, that Transaction Class name is used to classify the work with WLM.
Think about that for a moment. Order is going to be important. Suppose you have requests for an application with a context root of ‘myApp’ and you want to classify everything into one Transaction Class except the special case of a URL that starts ‘myApp/Special’. You’ll have one HTTP classification element that specifies a URL of ‘myApp*’ and another that specifies a URL of ‘myApp/Special’. Which one goes first? It has to be the specific ‘myApp/Special’ otherwise all requests including the special one will match the generic ‘myApp*’ element stop there. So specific rules first, then generic.
You might also want to have a catch-all HTTP classification element that specifies a URL of ‘*’ to match any other requests. Put that at the bottom of the list and specify a Transaction Class you want used for requests you’re not expecting (probably they don’t get a Service Class that is very important).
If you specify a Transaction Class that doesn’t match any classification rule in WLM, there is also a default Service and Report class for the CB subsystem (at the top of that screen) that will be used.
What if an HTTP request shows up that doesn’t match any HTTP classification element in your Liberty server config? That won’t happen if you have a catch-all at the bottom. But if you don’t, then no Transaction Class will be assigned and Liberty will skip the call to WLM letting it know about this request. WLM will remain unaware that it ran and processing done will be considered just part of the server overhead. Is this what you want? Probably not (hence the recommended catch-all element), but maybe there’s a case where that’s useful. But it is probably just a mistake.