![[V5.1 and later]](../../v51x.gif)
Native POSIX Threading Library (NPTL) support
All of this information is background information that is not necessary to understand to be able to use WebSphere Application Server, V5.1 on RHEL 3 or other Linux systems. The following information is provided to explain some dependencies of WebSphere Application Server, V5.1, and to provide education about some aspects of Linux about which you might have questions.
Be aware that the Native POSIX Threading Library is not supported with the WebSphere Application Server, V5.1 run time. NPTL is not supported because the embedded messaging feature requires specific LinuxThreads behaviors to function properly. NPTL and LinuxThreads are mutually exclusive.
The WebSphere Application Server run time is automatically configured to run under LinuxThreads at install time. No user intervention or environment exports are required.
Any attempt that you make to force WebSphere Application Server to use NPTL generates embedded messaging feature errors at start-up time. Such errors can cause appserver crashes.
The embedded messaging dependency on LinuxThreads does not, however, mean that all of the applications that are included with WebSphere Application Server, V5.1 must run under LinuxThreads. IBM HTTP Server, for example, runs under NPTL by default. The requirement for LinuxThreads is due strictly to the limitations that the embedded messaging JNI libraries impose on the run time code.
Differences between NPTL and LinuxThreads
Linux is undergoing a shift within a few of the libraries that compose the core of the Linux run time code. The library of significant concern is libpthread. This library provides normal implementation of threading (POSIX threads) that programs on the machine can use.
The behavioral changes caused by the change of the threading implementation cause significant problems within several complex applications. IBM provides as much support as possible for the latest threading implementation in IBM products. However, IBM cannot retrofit all existing and legacy applications to the newer NPTL threading implementation.
Retrofitting products would severely impact the stability of some legacy products and might affect customers with significant investment in legacy LinuxThreads implementations.
A brief description of each threading implementation follows.
LinuxThreads
LinuxThreads is the original implementation of POSIX threads for Linux. LinuxThreads is not fully POSIX compliant. In fact, LinuxThreads deviates significantly in certain areas.
For example, each thread in LinuxThreads has a visible PID to both the user and the application. Calling the getpid() function to get the process ID of the process returns a unique ID for each thread.
Because of this level of visibility, all child threads display when you run a ps -ef command. This exposure often causes customer confusion. A highly multi-threaded process (with 100 to 200 threads) looks as if it is actually 100 to 200 separate processes on the system. Another aspect of confusion is that the thread visibility makes it seem like single program is consuming far more memory than it actually is.
Other functions under LinuxThreads also do not conform to POSIX standards. An example includes the method of catching and distributing operating system signals in a multi-threaded application does not conform to the POSIX specification.
Many complex Linux applications, such as the Java Virtual Machine (JVM), must adapt to these irregularities to function properly.
This is the threading model that the WebSphere Application Server, Version 5.1 run time requires to function properly. JNI libraries used for the embedded messaging functionality impose the restriction to this threading model.
Native POSIX Threading Library (NPTL)
The Open Source community completely redesigned the libpthead threading implementation to create the Native POSIX Threading Library implementation. NPTL addresses the failings and limitations of LinuxThreads. The NPTL design addresses OS signal handling, expensive thread creation and destruction costs, and improving the efficiency of synchronization.
Also improved is the visibility of all thread PIDS. Internally, NPTL still uses a one-to-one kernel-to-user-thread mapping. However, updates to the getpid() function and to the getppid() function cause each function to return only the main PID. You should no longer see the multiple process IDs for child threads.
The visibility of the threads is reduced in system-level commands also. The ps –ef command displays only the main PID for the process.
NPTL is a far better threading implementation than LinuxThreads because of its thoughtful design. However, widespread adoption of the NPTL has not yet occurred because it is new. For example, the WebSphere Application Server installation guide describes one bug that IBM uncovered in the x86 implementation. IBM and Red Hat have since fixed the bug.
Another reason for the slow adoption of NPTL is that legacy applications and prerequisite product dependencies on LinuxThread behaviors limit the current exploitability of the new functionality.
The stated direction for the WebSphere Application Server product is to continue to work with related products within IBM and to work within the Open Source community to enable all IBM products to fully exploit the operating system enhancements of NPTL in future releases.
General Information regarding the LD_ASSUME_KERNEL and RPM_FORCE_NPTL environment variables
RHEL 3 recognizes both the LD_ASSUME_KERNEL environment variable and the RPM_FORCE_NPTL environment variable. These environment variables are not specific to WebSphere Application Server.
Use the environment variables only as directed within WebSphere Application Server, such as in the installation steps that describe a work around for a hang in processing for the installer program.
The following information helps explain what the environment variables do and how they affect the way that programs run on Linux.
Information about the LD_ASSUME_KERNEL environment variable
LD_ASSUME_KERNEL is an environment variable that allows over-riding the GLIBC run time that gets loaded with a particular application. The LD_ASSUME_KERNEL environment variable tells the dynamic linker (the part of the operating system that loads shared libraries) to override the default Application Binary Interface (ABI).
Values that the LD_ASSUME_KERNEL environment variable accepts as an override vary depending on the machine architecture. Override values of interest that relate to RHEL 3 are described in the following sections.
Hardware platform support for LD_ASSUME_KERNEL settings
| Hardware platform | LD_ASSUME_KERNEL = | ||
|---|---|---|---|
| 2.4.20 | 2.4.19 | 2.2.5 | |
| xSeries platform override values
(x86 or Intel architecture 32-bit machines)
| Yes | Yes | Yes |
| PowerPC (pSeries) and AS/400 (/iSeries) machines | Yes | Yes | No |
| S/390 zSeries machines | Yes | Yes | No |
Explanation of LD_ASSUME_KERNEL settings:
- LD_ASSUME_KERNEL=2.4.20
- This override requests the GLIBC/pthreads implementation that conforms
to kernel ABI version 2.4.20 or later. This implementation is the minimum
ABI required for NPTL. This is the default mode for RHEL 3.
Note: The WebSphere Application Server, V5.1 run time does not support NPTL.
- LD_ASSUME_KERNEL=2.4.19
- This override requests the GLIBC/pthreads implementation that conforms
to kernel ABI version 2.4.1. This implementation is commonly referred to as
standard LinuxThreads with floating stacks.
This implementation has been the standard implementation of threading on Linux for several years. The WebSphere Application Server, V5.1 run time requires this implementation.
Tip: The higher performing NPTL implementation has only recently replaced LinuxThreads with floating stack size as the default threading model in commercial distributions.
- LD_ASSUME_KERNEL=2.2.5
- This override requests the GLIBC/pthreads implementation that conforms
to kernel ABI version 2.4.0. This implementation is commonly referred to as
LinuxThreads with fixed stack size.
LinuxThreads with fixed stack size is the original implementation of threading for Linux. For the past several years, LinuxThreads with floating stacks has superseded this fixed stack size implementation. The fixed stack size implementation should be rarely, if ever, needed. Older legacy applications might require it.
Information about the RPM_FORCE_NPTL environment variable
RHEL 3, Update 1 or later recognizes the RPM_FORCE_NPTL environment variable. The environment setting instructs the software package installation tool (RPM) to always run under the NPTL threading model regardless of the threading model of the calling program.
This variable exists because WebSphere Application Server testing and analysis uncovered an error with regards to RPM function on RHEL 3. The error is that running RPM commands under LinuxThreads can cause RPM database corruption.
This problem is not specific to WebSphere Application Server. Any RPM installation-based application could encounter RPM DB corruption if executed under LinuxThreads. Such a scenario might be common within legacy applications being installed on RHEL 3.
Therefore, IBM recommends that you set the RPM_FORCE_NPTL environment variable whenever you set a value for LD_ASSUME_KERNEL that enables LinuxThreads. Set the variable to protect the integrity of the RPM database.
If you suspect a corrupt RPM database, try the following command to see if the database returns the information:
rpm – q –all
If the command hangs or reports an unusually small number of packages, try removing the RPM cache files with the following command:
rm -f /var/lib/rpm/__db.*
The deletion of the cache files does not adversely affect your operating system. The cache files provide quick indexing into the RPM database. Deleting the cache files clears out any bad entries that have been registered within the cache, but not yet committed into the main RPM database.
The cache files are rebuilt whenever an RPM command is run off the committed data in the RPM database.
If you continue to have problems, it is possible that some corrupt entries might have been committed into the RPM database. Contact Red Hat Support for help in such a case.