An Overview of Resin Native Optimizations
Given that Resin’s Unix installer is a ‘make’ script, and the Windows version includes .dll files, users are often inquisitive about how and why Resin makes use of native code. In this tip of the month I’ll discuss Resin’s native optimizations, what native optimizations are provided in Resin Pro vs Open-Source, and when the native libraries are occasionally required.
Resin is a Java application server with native optimizations. For the most part the native optimization are optional and Resin will run fine in pure Java mode. So if for some reason you have trouble compiling the native code on your platform, you’re only loosing out on some performance enhancements and optional features. This is discussed further below.
Resin uses native compiled code when available for increased performance and flexibility. The following is a list of the native optimizations available in Resin open-source:
- Optimized file I/O
- Optimized socket I/O
- Optimized and more flexible external processes execution
- Logging to Unix syslog
Resin Pro version includes a number of additional native optimizations not available in open-source:
- OpenSSL integration
- High-performance non-blocking sockets
- Heap dumps
- Performance profiling including CPU, network, load average, and VM statistics
- Random access and memory mapped files for caching
Resin’s Windows package includes precompiled 32-bit and 64-bit .dlls that Resin will load upon startup. These files are included in the win32/ and win64 directories. The Unix package is slightly more complicated since it requires compilation using a typical Unix style “configure; make; make install” sequence. Unix code will be compiled to libexec/ or libexec directory with a .so extension. The same locations for OSX except with the extension .jnilib.
When running Resin without without native libraries, you may see warnings in your resin log similar to the following:
[11-07-20 13:42:59.931] {main} JNI file: Unable to find native library 'resin' for com.caucho.vfs.JniFilePathImpl. Resin expects to find this library in:
(Mac OS X) /usr/local/resin/libexec64/libresin.jnilib
On Mac OS X, run ./configure --prefix=`pwd`; make; make install.
The JVM exception was: java.lang.UnsatisfiedLinkError: no resin in java.library.path
The error is harmless and only letting you know that native optimizations were not found, and where they should be located.
As mentioned, a few Resin features require native libraries. OpenSSL integration is probably the most important of these. A pure Java SSL alternative is available however using JSSE, although OpenSSL is preferred if possible. The Resin documentation includes a good reference on how to configure HTTPS with OpenSSL or JSSE.
Use of <user-name> and <group-name> configuration also requires native libraries. These tags cause the Resin process to execute as a different user for security purposes. Typically Resin would be started as “root” to enable binding to port 80, and then switch to user “nobody” or “resin”, which have restricted file access permissions. Executing processes as a different user is not something Java is capable of doing and thus requires native code.
Resin Pro includes both native heap dump and profiling capability that can be accessed from the web admin console or via command line. Newer JDKs include the jmap and visualvm utilities that are slightly less convenient alternatives.
Finally, logging to the Unix syslog daemon requires native libraries. There are some pure Java 3rd party syslog clients that may be used as an alternative.
As you can see from this overview, Resin resorts to native code only when necessary and where optimizations make the most sense. Resin Pro enhances this with OpenSSL support and convenient diagnostics.