The APR based Apache Tomcat Native Library which allows optimal performance in production environments is not found on th E-Java.library.path Problem solving

The TOMCAT boot message appears as follows:

Info: The APR based Apache Tomcat Native Library which allows optimal performance in production environments is not found O n the Java.library.path:XXXX

Cause Analysis:

Tomcat recommends using Apache's APR to better run Tomcat;

----------------------------------------------An Introduction to Apache Apr---------------------------------------------------

The APR (Apache portable run-time Libraries,apache Portable runtime) is designed to provide an underlying support interface library that can be used across multiple operating system platforms, as its name would be, primarily for upper-level applications. In earlier versions of Apache, the application itself must be able to handle the details of a variety of specific operating system platforms and invoke different processing functions for different platforms.

With the further development of Apache, the Apache organization decided to separate and develop these universal functions into a new project. In this way, the development of APR is isolated from Apache, and Apache uses only Apr.

APR enables the processing of platform details to move down. For applications, they do not need to consider the specific platform, whether UNIX, Linux or window, the application execution of the interface is basically consistent. Therefore, for APR, portability and a unified upper-level interface are an important consideration. This was not the first goal of APR, but it was originally intended to merge all the code used in Apache into a common codebase, but this was not the right strategy, so the APR changed its target later. Sometimes it is not a good thing to use public code, such as how to map a request to a thread or a process that is platform-dependent, so a common code base does not make this distinction. The goal of APR is to safely merge all the code that can be merged without sacrificing performance.

One of the first goals of APR is to provide a common, unified Operation function interface for all platforms (not parts), which is a great goal, and certainly unrealistic. We can't support all the features of all platforms, so APR is currently available for all APR feature support for most platforms, including Win32, OS/2, BeOS, Darwin, Linux, and more. In order to achieve this goal, APR developers must create a series of feature macros (FEATURE MACROS) for those features that cannot be run on all platforms to differentiate between the various platforms. These feature macro definitions are very simple and usually set with the Apr_has_feature parameter:

If a platform has this feature, the macro must be set to true, such as Linux and Windows have a memory-mapped file, and APR provides the operating interface of the memory-mapped file, so on these two platforms, the APR_HAS_MMAP macro must be set, while the ap_mmap_* The function should map the disk file to memory and return the appropriate status code. If your operating system does not support memory mapping, then Apr_has_mmap must be set to 0, and all ap_mmap_* functions may not need to be defined. The second step is to warn those who use unsupported functions in the program.

Workaround:

http://archive.apache.org/dist/tomcat/tomcat-connectors/native/download with your Tomcat counterpart version of Tcnative-1.dll, put it in under the Apache-tomcat-7.0.57\bin directory, restart Tomcat;

If you don't know the version, you can download a version, put it in the directory, and when you restart Tomcat, you will be prompted with the appropriate version of Tcnative-1.dll ;

1.

2.

3.

4.

The APR based Apache Tomcat Native Library which allows optimal performance in production environments is not found on th E-Java.library.path Problem solving