Tomcat Connector Implementation Details: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
Line 21: Line 21:
* curThreadsBusy is decremented
* curThreadsBusy is decremented


The ''idle'' Worker instances are referred from the 'worker' array of the WorkerStack instance. All idle workers wait on a notification that a new socket has been allocated to one of them, at which time the Worker instance with the newly allocated socket will pop from the WorkerStack and start reading from the socket. Every time this happens, the 'tcpNoDelay', 'soLinger' and 'soTimeout' socket properties are set, if they have been configured on the connector. For more details on socket options see [tcpNoDelay|TomcatAJPConnector#TcpNoDelay], [soLinger|TomcatAJPConnector#SoLinger], [soTimeout|TomcatAJPConnector#SoTimeout].
The ''idle'' Worker instances are referred from the 'worker' array of the WorkerStack instance. All idle workers wait on a notification that a new socket has been allocated to one of them, at which time the Worker instance with the newly allocated socket will pop from the WorkerStack and start reading from the socket. Every time this happens, the [[Tomcat_Configuration#tcpNoDelay|tcpNoDelay]], [[Tomcat_Configuration#soLinger|soLinger]] and [[Tomcat_Configuration#soTimeout|soTimeout]]' socket properties are set, if they have been configured on the connector.  


So far, I was not able to identify any condition that would shut-down threads that are idle. Apparently, once a thread is started, will stay in the WorkerStack forever (when it is not used).
So far, I was not able to identify any condition that would shut-down threads that are idle. Apparently, once a thread is started, will stay in the WorkerStack forever (when it is not used).

Revision as of 18:48, 10 May 2017

Internal

Relevance

  • JBoss 5.1.1

Overview

The JIoEndpoint's acceptor thread continuously blocks in accepting connections on the server socket. Once such a connection attempt is made, the acceptor thread pops an idle Worker instance from the WorkerStack (incrementing curThreadsBusy in the process) and assigns the newly accepted Socket instance to it. This assignment triggers a monitor notification that awakes the appropriate worker thread, which starts reading from socket. If no workers are yet created, the acceptor thread creates an instance.

There is a one-to-one relationship between the socket, the AJP worker instance, the AJP thread processing the requests ("ajp-127.0.0.1-8009-1") and an AjpProcessor object instance.

The AjpProcessor instance continuously loops reading from the associated socket. As long as the single-threaded processing pipeline is in this state, the thread is accounted as busy. The time interval the thread waits to read from the socket for the subsequent request is controlled by keepAliveTimeout.

When a socket read 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" in the 'workers' array.
  • curThreadsBusy is decremented

The idle Worker instances are referred from the 'worker' array of the WorkerStack instance. All idle workers wait on a notification that a new socket has been allocated to one of them, at which time the Worker instance with the newly allocated socket will pop from the WorkerStack and start reading from the socket. Every time this happens, the tcpNoDelay, soLinger and soTimeout' socket properties are set, if they have been configured on the connector.

So far, I was not able to identify any condition that would shut-down threads that are idle. Apparently, once a thread is started, will stay in the WorkerStack forever (when it is not used).