Compatibility :3.5.8
Editions :Professional EditionStandard EditionCommunity Edition
Platforms :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

The Wrapper needs to maintain constant communication between the Wrapper process and a class running within the JVM. This communication has traditionally been done using a socket across the loopback device (localhost). This has been safe and reliable but some users have requested an alternative because of security or other issues.

In two known instances, users reported that their backend socket was being closed by an external process while running on Windows 2003. The cause of the closures were never discovered, but this was the impetus for implementing an alternative communication method using pipes.

This is what was seen in the logs when this happened with debug output enabled in the wrapper.debug property:

DEBUG  | wrapperp | socket send failed.  An existing connection was forcibly closed by the remote host. (0x2746)
DEBUG  | wrapperp | closing backend socket.
INFO   | jvm 1    | WrapperManager Debug: Closed socket: java.net.SocketException: Connection reset
INFO   | jvm 1    | WrapperManager Debug: Returned from socket handler.
INFO   | jvm 1    | WrapperManager Debug: Closing backend socket.
INFO   | jvm 1    | WrapperManager Error: The backend socket was closed unexpectedly.  Restart to resync with the Wrapper.

When this happens, the Wrapper restarts the JVM without further problems, but for some applications, a JVM restart can cause problems of its own and is best to be avoided.

The default value is "AUTO".

List of possible values:

  • AUTO: use SOCKET and in case of error, fallback to PIPE
  • SOCKET: use SOCKET_IPv4 and in case of error, fallback to SOCKET_IPv6
  • SOCKET_IPv4: use a IPv4 socket
  • SOCKET_IPv6: use a IPv6 socket
  • PIPE: use a pipe backend

Reference: Port