title: How do Jetty and other containers leverage NIO while sticking to the Servlet specification?
body: <p>I'm new to NIO, and I am trying to figure out how Jetty leverages NIO. </p>
  
  <p><strong>My understanding of how traditional servlet containers that use Blocking IO service a request is as follows:</strong></p>
  
  <ol>
  <li>A request arrives</li>
  <li>A thread is allocated to process the request and the servlet method (<code>doGet</code> etc) is invoked</li>
  <li>Servlet method is handed an <code>InputStream</code> and <code>OutputStream</code></li>
  <li>The servlet method reads from the <code>InputStream</code> and writes to the <code>OutputStream</code></li>
  <li>The <code>InputStream</code> and <code>OutputStream</code> are basically tied to the respective streams of the underlying <code>Socket</code></li>
  </ol>
  
  <p><strong>What is different when an NIO connector is used? My guess is along the following lines:</strong></p>
  
  <ol>
  <li>A request arrives</li>
  <li>Jetty uses NIO connector and buffers the entire request asynchronously</li>
  <li>Once request has been read completely wrap the buffer in an <code>InputStream</code></li>
  <li>Create an empty response buffer (wrapped in an <code>OutputStream</code>)</li>
  <li>Allocate a thread and invoke the servlet method (<code>doGet</code> etc) handing the above wrapper streams</li>
  <li>Servlet method writes to the wrapped (buffered) response stream and returns from the servlet method</li>
  <li>Jetty uses NIO to write the response buffer contents to the underlying <code>SocketChannel</code></li>
  </ol>
  
  <p><strong>From the Jetty documentation, I found the following:</strong></p>
  
  <p><a href="http://wiki.eclipse.org/Jetty/Howto/Configure_Connectors#SelectChannelConnector">SelectChannelConnector</a> - This connector uses efficient NIO buffers with a non-blocking threading model. Jetty uses Direct NIO buffers, and allocates threads only to connections with requests. Synchronization simulates blocking for the servlet API, and any unflushed content at the end of request handling is written asynchronously.</p>
  
  <p>I'm not sure I understand what <em><code>Synchronization simulates blocking for the servlet API</code></em> means?</p>