Compatibility :	3.5.8
Editions :
Platforms :

The Wrapper needs to maintain constant communicate 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 proparty :

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.

At the time of this writing, this property is still experimental. The default value is "SOCKET".

• To make use of the default socket backend, use "SOCKET".
• For the new pipe backend, use "PIPE".

wrapper.backend.type=SOCKET

• wrapper.backend.type

• wrapper.port
• wrapper.port.max
• wrapper.port.min

• wrapper.jvm.port
• wrapper.jvm.port.max
• wrapper.jvm.port.min