Tomcat Configuration

Internal

• Tomcat

TODO

• AccessLogValve: https://home.feodorov.com:9443/wiki/Wiki.jsp?page=JBossLoggingForTroubleshootingWebApplications

Connector Configuration

<!-- A AJP 1.3 Connector on port 8009 -->
<Connector port="8009" address="${jboss.bind.address}"
           enableLookups="false" redirectPort="8443" debug="0"
           protocol="AJP/1.3"/>

For more details on Connectors, see

Tomcat Concepts - Connector

maxThreads

Make sure the value configured for maxThreads at least matches the value of mod_jk2 max_connections, configured in workers2.properties file.

keepAliveTimeout

Represents the number of milliseconds the connector (AjpProcessor instance, for example) will wait for a subsequent request before closing the connection. If not set in the configuration, Tomcat won't attempt to set it on the socket, which means the AjpProcessor instance will read from socket indefinitely.

Internally, it is implemented invoking java.net.Socket#setSoTimeout() on the associated socket. According to the Socket class documentation, the call enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be higher than 0. A timeout of zero is interpreted as an infinite timeout.

When the timeout occurs:

• The AjpProcessor instance is added to the recycled processor queue maintained by the AjpConnectionHandler instance
• The underlying socket is closed
• The Worker instance is stored as "idle"
• curThreadsBusy is decremented

soTimeout

Has the same effect as setting 'keepAliveTimeout' above.

Also see

SO TIMEOUT

tcpNoDelay

Enable/disable TCP_NODELAY on the underlying socket. See

TCP_NODELAY

!!!soLinger

Enable/disable SO_LINGER with the specified linger time in seconds. The maximum timeout value is platform specific. The setting only affects socket close.

The purpose of SO_LINGER is very specific and only a tiny minority of socket applications actually need it. The effect of an setsockopt(..., SO_LINGER,...) depends on what the values in the linger structure (the third parameter passed to setsockopt()) are:

• Case 1: {{linger->l_onoff}} is zero. This is the default. On close(), the underlying stack attempts to gracefully shutdown the connection after ensuring all unsent data is sent. In the case of connection-oriented protocols such as TCP, the stack also ensures that sent data is acknowledged by the peer. The stack will perform the above-mentioned graceful shutdown in the background (after the call to close() returns), regardless of whether the socket is blocking or non-blocking.
• Case 2: {{linger->l_onoff}} is non-zero and {{linger->l_linger}} is zero. A close() returns immediately. The underlying stack discards any unsent data, and, in the case of connection-oriented protocols such as TCP, sends a RST (reset) to the peer (this is termed a hard or abortive close). All subsequent attempts by the peer's application to read()/recv() data will result in an ECONNRESET.
• Case 3: {{linger->l_onoff}} is non-zero and {{linger->l_linger}} is non-zero. A close() will either block (if a blocking socket) or fail with EWOULDBLOCK (if non-blocking) until a graceful shutdown completes or the time specified in linger->l_linger elapses (time-out). Upon time-out the stack behaves as in case 2 above.