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.
---------------
One of the cool things about Liberty is that configuration and application changes take effect immediately. If you have a running server and replace the .war file for an application in that server or update server.xml (or some file it includes) the server will see the change happened and stop and start the application etc. For a developer that’s very cool. You never have to look at the time stamp on a file and compare it to the last start time of the server to see if you remembered to restart after the change or not (I speak from experience). Of course, it is still possible to make a config change and forget to actually save the file, just leaving the editor open with the change made. Not that I’ve done that..
But, in a production environment, changes are far less frequent and quite often strictly managed and (except in emergencies) come at scheduled times. And then there’s the cost of that magical config change detection. For that to work, the server wakes up every half second (that’s configurable) to see if anything changed. Again, for a developer that means any change takes effect essentially immediately. But in production that’s CPU you’re burning for no purpose pretty much all the time. And on z/OS where you might be charged for CPU usage, that’s bad.
Thus most z/OS production Liberty servers have disabled this configuration monitoring. And that means that any changes require the server to be restarted to pick it up. For the server itself that isn’t a big deal since Liberty starts so fast the outage could be just a few seconds. But applications can sometimes take a bit longer to get restarted and if your change didn’t involve an application change, that application restart might not be necessary.
Which led to the creation of z/OS console Modify commands that internally drive an MBean that kicks the same config scanning that normally happens automatically. So if you change the scanning so it doesn’t happen automatically, but instead enable MBean driven changes, the Modify command will work. You can, of course, drive the MBean yourself if you want to.
Which means that you could make all your changes that have gone through whatever change control process you have ahead of your change window. Those changes won’t get picked up automatically because you turned that off. And then, when your change window comes along, you issue the Modify command to scan for changes. That will drive one pass through the code that normally runs automatically every half-second. It will pick up your changes and activate them. And there you go.
You might issue that Modify command manually when know you have changes to activate, or you could just have automation issue it in your designated window (midnight on Saturday anybody?) to pick up whatever changes got made before then. Be sure your operations procedure has somebody else’s phone number in there first :-)