diff options
Diffstat (limited to 'jdisc_http_service/docs/httpserver.html')
| -rw-r--r-- | jdisc_http_service/docs/httpserver.html | 96 |
1 files changed, 0 insertions, 96 deletions
diff --git a/jdisc_http_service/docs/httpserver.html b/jdisc_http_service/docs/httpserver.html deleted file mode 100644 index 66afeb687fe..00000000000 --- a/jdisc_http_service/docs/httpserver.html +++ /dev/null @@ -1,96 +0,0 @@ -<!-- Copyright 2016 Yahoo Inc. Licensed under the terms of the Apache 2.0 license. See LICENSE in the project root. --> -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" -<!-- Copyright 2016 Yahoo Inc. Licensed under the terms of the Apache 2.0 license. See LICENSE in the project root. --> - "http://www.w3.org/TR/html4/loose.dtd"> -<html> -<head> - <title>HTTP Server Architecture</title> - <style type="text/css"> - body { - font: 13px/1.231 arial,helvetica,clean,sans-serif; - *font-size: small; - *font: x-small; - } - select,input,button,textarea { - font: 99% arial,helvetica,clean,sans-serif; - } - table{ - font-size: inherit; - font: 100%; - } - pre,code,kbd,samp,tt { - font-family: monospace; - *font-size: 108%; - line-height: 100%; - } - </style> -</head> -<body> -<p>The HTTP server is started by calling <code>HttpServer.start()</code>, which in turn calls <code>ServerBootstrap.bind()</code> - provided by - Netty.</p> - -<img src="class-diagram.png" alt="Class diagram"> - -<p>Since our HttpServer implements <code>ChannelPipelineFactory</code> (provided by jetty), its - <code>getPipeline()</code> method is called for every new channel that is connected. There is hence a one-to-many - relationship between a <code>HttpServer</code> and a pipeline (and a one-to-one relationship between an actual - channel and a pipeline).</p> - -<p>The pipeline is responsible for decoding (and possibly deflating etc.) every new request that is received on a - channel. The final element in the pipeline is a <code>ChannelContext</code>, which is the jDISC class for handling - requests on a channel.</p> - -<p>The <code>ChannelContext</code> implements <code>SimpleChannelUpstreamHandler</code> (provided by Jetty), which has - simple callback methods for various event types. <br/>Examples:</p> - -<ul> - <li><code>channelConnected()</code></li> - <li><code>channelDisconnected()</code></li> - <li><code>messageReceived()</code></li> -</ul> - -<p>Since <code>ChannelContext</code> supports HTTP keep-alive and HTTP pipelining, it needs to keep track of multiple - requests made on the channel, and their order.</p> - -<p>In <code>messageReceived()</code> it will:</p> -<ul> - <li>Determine if the element received is a new HTTP request, or a chunk belonging to the previous one.</li> - <li>If it's a request, create a DISC <code>Request</code> object for it, and call <code>Request.connect()</code>, - which will in turn give it to the actual application, through the use of - <code>RequestHandler.handleRequest()</code>. - </li> - <li>If it's a chunk, fetch the previously added <code>RequestContext</code>, and use it to write the data received - into the <code>ContentChannel</code>. - </li> -</ul> - -<p><code>RequestContext</code> keeps track of a request and its input and output <code>ContentChannel</code>s, and - related objects. Since <code>RequestContext</code> is a <code>ResponseHandler</code>, it is responsible for - instantiating and returning a <code>ContentChannel</code> when an application calls <code>handleResponse()</code>. - Two types are supported, one that supports HTTP response chunking, and one that does not. The type used is chosen - automatically based on HTTP version, headers etc.</p> - -<p>Since the jDISC API is fully asynchronous, operations can occur in any order. This is very extensively tested in the - HTTP server implementation. For instance, an application (<code>RequestHandler</code>) may choose to respond and - close the output <code>ContentChannel</code> immediately upon receiving the request, before the body of the request - has been written into the input <code>ContentChannel</code> of the <code>RequestHandler</code>. All such cases are - tested and properly handled.</p> - -<p>As one can see from the illustration, <code>ChannelContext</code> is also a <code>Runnable</code>, i.e. it keeps one - thread per channel. The HTTP server has two modes of operation, <code>optimizeForPipeline</code> <code>true</code> - or <code>false</code> in <code>HttpServerConfig</code>.</p> - -<p>If <code>optimizeForPipeline</code> is set to <code>true</code>, response chunks are enqueued on a blocking queue in - <code>ChannelContext</code> when <code>ContentChannel.write()</code> is called. The <code>ChannelContext</code> - thread is responsible for actually writing them, and closing the channel when appropriate. Since the HTTP server - supports pipelining, and writes from an application may occur in any order, special care is taken to write response - chunks in the correct order.</p> - -<p>If <code>optimizeForPipeline</code> is set to <code>false</code>, a call to <code>ContentChannel.write()</code> will - lead to an actual write on the wire, iff. the given chunk to be written is the next in line. Otherwise this is a - no-op. This also means that a <code>ContentChannel.write()</code> may lead to a cascade of writes that have been - enqueued since they were out-of-order when their <code>write()</code> was called. The <code>ChannelContext</code> - thread still takes care of channel closing in most cases.</p> -</body> -</html> |