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.
---------------
The ‘normal’ way for an application to wait for data over a TCP/IP connection is to have a thread blocked in a ‘read’ waiting for it. This won’t scale very well if you have an application server connected to a few thousand clients concurrently.
The solution is to have some sort of asynchronous interface so that one thread can wait on behalf of a lot of connections and get notified when something happens. There are platform neutral ways to do that in Java, but on z/OS we’ve got a cool thing built right in.
The TCP/IP stack on z/OS supports a set of async I/O APIs (usually accessed through USS or LE APIs). The mechanism we choose to be notified about new data (or new connections on a listener) is through an SRB. An SRB is the ‘other’ form of a dispatchable unit of work on z/OS. The main one is the TCB or task or thread. When data (or a connection) shows up, TCP/IP schedules an SRB to run in the reader/listeners address space which branches to code provided by the reader/listener.
In some cases it might be possible to take action based on what was received right there in the SRB (WebSphere traditional on z/OS does this when an IIOP Locate request arrives because a response can be built and sent right from the SRB). In Liberty we need to ‘wake up’ a thread and let it know something happened. But multiple SRBs can be running concurrently and the thread can ‘grab’ multiple things at once and iterate through them to throw work to the executor pool of threads. All this means it runs faster and scales better than doing it the normal way.
To get this behavior you just need to allow the server to use the APIs. Because an SRB runs ‘authorized’ using this flavor of the TCP/IP APIs requires authorization and thus an Angel. You’ll also need access to the ZOSAIO resource within that Angel.
If you grant access but later decide you don’t want to use it (maybe to do some performance comparisons) and don’t want to hassle your security guy every time you want to go back and forth, there’s also a bootstrap.properties value you can set:
com.ibm.ws.tcpchannel.useZosAio=false
to disable it even though you have access to the required Angel service.