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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to