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.
---------------
Alright, so you’ve decided you need an Angel for your Liberty server to have access to one or more authorized services. You get the server all configured, your apps all deployed, you start the server up and it comes right up, no problem. Except…you forgot to start the Angel. What happens?
Well, the server will try to connect to the Angel (either the default one or the named one you told it to connect to) and that fails. The Angel is, as far as Liberty is concerned, optional, so this is just fine with the server. You might have configured some features that need the Angel to function, but you’ll just get messages telling you those services aren’t available (because you’re looking at all the messages the server issued when it starts up, right?).
Ok, so that’s awful. You aren’t getting the behavior you want, but unless you look close you can’t tell until things don’t work or you don’t get the WLM classification you want etc. How can you tell the server you don’t just WANT an Angel to be used, you NEED an Angel to be used? Well, there’s a bootstrap property you can configure called com.ibm.ws.zos.core.angelRequired. If you set that to true, it tells the server that you NEED an Angel and if it can’t find the one it wants (or fails connecting to it) then the server will shut down.
That’s great, but your server also NEEDS access to certain authorized services in order to function properly. The property above just guarantees you can connect to an Angel, but if you didn’t do the proper SAF permission set up your server won’t be able to use any of it. This leads to a second bootstrap property (same com.ibm.etc) called angelRequiredServices. You set this to a list of those service names (the same ones you give access to and that show up in the messages at startup). When the server connects to the Angel, it will check that it has access to those services and if it doesn’t then the server will shut down (with appropriate messages explaining why). It also won’t bother checking access to any other services that might be available, but will just assume you don’t have access because you said you didn’t need it. So be sure the list includes all the things you need, even if the server actually has access to more.
Alright, so you got all that set up and now you want to have automation start this as a production server. The automation folks see you need the server and an Angel so they add automation to just start ‘em both up. Well, now you’ve got a race. If the Angel gets up first, the server can connect to it, but if the server gets far enough along to look for the Angel you configured it to require before the Angel gets all the way up, the server will fail to start. Now you could have a chat with the automation folks and have them start them staggered or have the server wait to start until the Angel is up. But if you’ve burned up all your favors with your automation folks, you could always set com.ibm.ws.zos.core.angelWaitTimeSeconds in bootstrap.properties. This tells the server that if it can’t find the Angel it needs, it should wait up to this many seconds for the Angel to turn up. Depending on your system, setting this to 5 or 10 (or 30) seconds might be enough to avoid the problem.