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 alternate 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
Configures the communication between the Wrapper's process and the class running within the JVM.