[Httpcomponents Wiki] Update of "HttpCoreTutorial" by MichaelClark

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" for change notification.

The following page has been changed by MichaelClark:
http://wiki.apache.org/HttpComponents/HttpCoreTutorial

The comment on the change is:
I fixed some typos, and rephrased a few sentences for clarity (not content.)

------------------------------------------------------------------------------
  
  ==== HTTP request handlers ====
  
- !HttpRequestHandler interface represents a routine for processing of a specific group of HTTP requests. !HttpService is designed to take care of protocol specific aspects, whereas individual request handlers are expected to take care of application specific HTTP processing. The main purpose of a request handler is to generate a response object with a content entity to be sent back to the client in response to the given request.
+ The !HttpRequestHandler interface represents a routine for processing of a specific group of HTTP requests. !HttpService is designed to take care of protocol specific aspects, whereas individual request handlers are expected to take care of application specific HTTP processing. The main purpose of a request handler is to generate a response object with a content entity to be sent back to the client in response to the given request.
  
  {{{
  HttpRequestHandler myRequestHandler = new HttpRequestHandler() {
@@ -694, +694 @@

  
  ==== Using HTTP service to handle requests ====
  
- When fully initialized and configured, the !HttpService can be used to execute and handle requests for active HTTP connections. !HttpService#!handleRequest() method reads an incoming request, generates a response and sends it back to the client. This method can be executed in a loop to handle multiple requests on a persistent connection. The !HttpService#!handleRequest() is safe to execute from multiple threads to process requests on several connections simultaneously as long as protocol interceptors and requests handlers used by the !HttpService are thread safe.
+ When fully initialized and configured, the !HttpService can be used to execute and handle requests for active HTTP connections. The !HttpService#!handleRequest() method reads an incoming request, generates a response and sends it back to the client. This method can be executed in a loop to handle multiple requests on a persistent connection. The !HttpService#!handleRequest() method is safe to execute from multiple threads. This allows processing of requests on several connections simultaneously, as long as all the protocol interceptors and requests handlers used by the !HttpService are thread safe.
  
  {{{
  HttpService httpService;
@@ -716, +716 @@

  
  === HTTP request executor ===
  
- !HttpRequestExecutor is a client side HTTP protocol handler based on the blocking I/O model that implements the essential requirements of the HTTP protocol for the client side message processing as described by RFC 2616. !HttpRequestExecutor, similarly to its server side counterpart, makes use of !HttpProcessor to take care of the cross-cutting protocol aspects that apply to all incoming and outgoing messages. Application specific processing can be implemented outside !HttpRequestExecutor once the request has been executed and a response has been received.
+ !HttpRequestExecutor is a client side HTTP protocol handler based on the blocking I/O model that implements the essential requirements of the HTTP protocol for the client side message processing, as described by RFC 2616. !HttpRequestExecutor, similarly to its server side counterpart, makes use of !HttpProcessor to take care of the cross-cutting protocol aspects that apply to all incoming and outgoing messages. Application specific processing can be implemented outside !HttpRequestExecutor once the request has been executed and a response has been received.
  
  {{{
  HttpClientConnection conn;
@@ -743, +743 @@

  }
  }}}
  
- Methods of !HttpRequestExecutor are safe to execute from multiple threads to execute requests on several connections simultaneously as long as protocol interceptors used by the !HttpRequestExecutor are thread safe.
+ Methods of !HttpRequestExecutor are safe to execute from multiple threads.  This allows execution of requests on several connections simultaneously, as long as all the protocol interceptors used by the !HttpRequestExecutor are thread safe.
  
  === Connection persistence / re-use ===
  
@@ -753, +753 @@

   
  == Benefits and shortcomings of the non-blocking I/O model ==
  
- Contrary to the popular belief, the performance of NIO in terms of raw data throughput is significantly lower than than of the blocking I/O. NIO does not necessarily fit all use cases and should be used only where appropriate: 
+ Contrary to the popular belief, the performance of NIO in terms of raw data throughput is significantly lower than that of blocking I/O. NIO does not necessarily fit all use cases and should be used only where appropriate: 
      
   * handling of thousands of connections, a significant number of which can be idle 
  
@@ -773, +773 @@

      
  == I/O reactor ==
  
- !HttpCore NIO is based on the Reactor pattern as described by Doug Lea. The purpose of I/O reactors is to react to I/O events and to dispatch event notifications to individual I/O sessions. The main idea of I/O reactor pattern is to break away from the one thread per connection model imposed by the classic blocking I/O model. !IOReactor interface represents an abstract object implementing the Reactor pattern. Internally, !IOReactor implementations encapsulate functionality of the NIO !Selector.
+ !HttpCore NIO is based on the Reactor pattern as described by Doug Lea. The purpose of I/O reactors is to react to I/O events and to dispatch event notifications to individual I/O sessions. The main idea of I/O reactor pattern is to break away from the one thread per connection model imposed by the classic blocking I/O model. The !IOReactor interface represents an abstract object implementing the Reactor pattern. Internally, !IOReactor implementations encapsulate functionality of the NIO !Selector.
  
  I/O reactors usually employ a small number of dispatch threads (often as few as one) to dispatch I/O event notifications to a much greater number (often as many as several thousands) of I/O sessions or connections. It is generally recommended to have one dispatch thread per CPU core.
  
@@ -820, +820 @@

  
  === I/O sessions ===
  
- I/O session represents a sequence of logically related data exchanges between two end points. I/O session encapsulates functionality of NIO !SelectionKey and !SocketChannel. One can use the channel associated with the I/O session to read from and data from it. 
+ The !IOSession interface represents a sequence of logically related data exchanges between two end points. !IOSession encapsulates functionality of NIO !SelectionKey and !SocketChannel. The channel associated with the !IOSession can be used to read data from and write data to the session.
  
  {{{
  IOSession iosession;

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org