Index: src/docbkx/nio-ext.xml =================================================================== --- src/docbkx/nio-ext.xml (revision 1065491) +++ src/docbkx/nio-ext.xml (working copy) @@ -445,7 +445,7 @@ I/O reactor exception handling Protocol specific exceptions as well as those I/O exceptions thrown in the course of - interaction with the session's channel are to be expected are to be dealt with by specific + interaction with the session's channel are to be expected and are to be dealt with by specific protocol handlers. These exceptions may result in termination of an individual session but should not affect the I/O reactor and all other active sessions. There are situations, however, when the I/O reactor itself encounters an internal problem such as an I/O @@ -802,7 +802,7 @@ Content codes are optimized to read data directly from or write data directly to the underlying I/O session's channel, whenever possible avoiding intermediate buffering in a session buffer. Moreover, those codecs that do not perform any content transformation - such as Content-Length delimited and identity can leverage NIO + such as Content-Length ?delimited and identity? can leverage NIO java.nio.FileChannel methods for significantly improved performance of file transfer operations both inbound and outbound. @@ -1031,7 +1031,7 @@ classic I/O abstraction based on inherently blocking java.io.InputStream and java.io.OutputStream classes is not applicable to the asynchronous process of data transfer. Therefore, non-blocking HTTP entities provide - NIO specific extensions to the !HttpEntity interface: ProducingNHttpEntity + NIO specific extensions to the HttpEntity interface: ProducingNHttpEntity and ConsumingNHttpEntity interfaces. Implementation classes of these interfaces may throw java.lang.UnsupportedOperationException from @@ -1663,13 +1663,13 @@ ThrottlingHttpClientHandler are protocol handler implementations that provide compatibility with the blocking I/O model by utilizing shared content buffers and a fairly small pool of worker threads. The throttling protocol handlers - allocate input / output buffers of a constant length upon initialization and - control the rate of I/O events in order to ensure those content buffers does not + allocate input / output buffers of constant length upon initialization and + control the rate of I/O events in order to ensure those content buffers do not ever overflow. This helps ensure nearly constant memory footprint for HTTP connections and avoid out of memory conditions while streaming content in and out. Request / response processing callbacks fire immediately when a message is received. The throttling protocol handlers delegate the task of processing requests - and generating response content to an !Executor, which is expected to perform those + and generating response content to an Executor, which is expected to perform those tasks using dedicated worker threads in order to avoid blocking the I/O thread. @@ -1810,7 +1810,7 @@ Triggered when the SSL connection has been established and initial SSL handshake has been successfully completed. The handler can use this - callback to verify properties of the !SSLSession. For instance this would + callback to verify properties of the SSLSession. For instance this would be the right place to enforce SSL cipher strength, validate certificate chain and do hostname checks. @@ -1861,7 +1861,7 @@ SSLServerIOEventDispatch I/O dispatch implementations that can be used to SSL enable connections managed by any arbitrary I/O reactor. The dispatches take all the necessary actions to wrap active I/O sessions with the SSL I/O session decorator - and ensure correct handling of the SSL protocol handshaking. + and ensure correct handling of SSL protocol handshaking.