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 AJP connector (AjpProcessor instance) will wait for a subsequent request before closing the connection. If not set in the configuration, JBossWeb 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

What is the corresponding parameter on the httpd side?

!!!soTimeout

Has the same effect as setting 'keepAliveTimeout' above.

Also see

|[JavaSocket#SO_TIMEOUT]

!!!tcpNoDelay

Enable/disable TCP_NODELAY (disable/enable Nagle's algorithm). TCP_NODELAY disables the Nagle buffering algorithm. It should only be set for applications that send frequent small bursts of information without getting an immediate response, where timely delivery of data is required (the canonical example is mouse movements). Nagle's algorithm works by combining a number of small outgoing messages, and sending them all at once. Specifically, as long as there is a sent packet for which the sender has received no acknowledgment, the sender should keep buffering its output until it has a full packet's worth of output, so that output can be sent all at once.

|[1]

!!!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.