[grizzly~git:a3441750] [2.3.x] Checkpoint of site work.

  • From: rlubke@...
  • To: commits@...
  • Subject: [grizzly~git:a3441750] [2.3.x] Checkpoint of site work.
  • Date: Wed, 24 Apr 2013 18:21:31 +0000

Project:    grizzly
Repository: git
Revision:   a344175045a39588159e651b3f0e87f2f60722af
Author:     rlubke
Date:       2013-04-24 18:20:38 UTC
Link:       

Log Message:
------------
[2.3.x] Checkpoint of site work.



Revisions:
----------
a344175045a39588159e651b3f0e87f2f60722af


Modified Paths:
---------------
pom.xml


Added Paths:
------------
site/pom.xml
site/src/site/markdown/contribute.md
site/src/site/markdown/documentation/ajp.md
site/src/site/markdown/documentation/bestpractices.md
site/src/site/markdown/documentation/comet.md
site/src/site/markdown/documentation/coreconfig.md
site/src/site/markdown/documentation/coreframeworksamples.md
site/src/site/markdown/documentation/dependencies.md
site/src/site/markdown/documentation/filterchainfilters.md
site/src/site/markdown/documentation/httpframework.md
site/src/site/markdown/documentation/httpserverframework.md
site/src/site/markdown/documentation/httpserverframeworkextras.md
site/src/site/markdown/documentation/iostrategies.md
site/src/site/markdown/documentation/jaxws.md
site/src/site/markdown/documentation/memory.md
site/src/site/markdown/documentation/monitoring.md
site/src/site/markdown/documentation/overview.md
site/src/site/markdown/documentation/portunification.md
site/src/site/markdown/documentation/quickstart.md
site/src/site/markdown/documentation/samples.md
site/src/site/markdown/documentation/spdy.md
site/src/site/markdown/documentation/transportsconnections.md
site/src/site/markdown/documentation/websockets.md
site/src/site/markdown/index.md
site/src/site/resources/css/site.css
site/src/site/resources/images/compass.png
site/src/site/resources/images/download.png
site/src/site/resources/images/grizzlyHead.png
site/src/site/resources/images/settings.png
site/src/site/resources/images/twitter.png
site/src/site/site.xml


Diffs:
------
--- a/pom.xml
+++ b/pom.xml
@@ -333,7 +333,8 @@
         <module>samples/</module>
         <module>extras/</module>
         <module>documentation/</module>
-    </modules>    
+        <!-- <module>site/</module> -->
+    </modules>
     <reporting>
         <outputDirectory>target/site</outputDirectory>
         <plugins>--- /dev/null
+++ b/site/pom.xml
@@ -0,0 +1,50 @@
+<project xmlns="http://maven.apache.org/POM/4.0.0";
+         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 ;
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
+    <parent>
+        <artifactId>grizzly-project</artifactId>
+        <groupId>org.glassfish.grizzly</groupId>
+        <version>2.3.2-SNAPSHOT</version>
+    </parent>
+    <modelVersion>4.0.0</modelVersion>
+
+    <artifactId>site</artifactId>
+    <packaging>pom</packaging>
+
+    <distributionManagement>
+        <site>
+            <id>website</id>
+            <url>scp://webhost.company.com/www/website</url>
+        </site>
+    </distributionManagement>
+    <build>
+        <plugins>
+            <plugin>
+                <groupId>org.apache.maven.plugins</groupId>
+                <artifactId>maven-site-plugin</artifactId>
+                <version>3.2</version>
+                <dependencies>
+                    <dependency>
+                        <groupId>org.apache.maven.doxia</groupId>
+                        <artifactId>doxia-module-markdown</artifactId>
+                        <version>1.3</version>
+                    </dependency>
+                    <dependency>
+                        <groupId>lt.velykis.maven.skins</groupId>
+                        <artifactId>reflow-velocity-tools</artifactId>
+                        <version>1.0.0</version>
+                    </dependency>
+                    <!-- Reflow skin requires Velocity >= 1.7  -->
+                    <dependency>
+                        <groupId>org.apache.velocity</groupId>
+                        <artifactId>velocity</artifactId>
+                        <version>1.7</version>
+                    </dependency>
+                </dependencies>
+            </plugin>
+        </plugins>
+    </build>
+    <properties>
+        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+    </properties>
+</project>--- /dev/null
+++ b/site/src/site/markdown/contribute.md
@@ -0,0 +1,15 @@
+# Contribute
+
+High level project contribution details
+
+## Issues (bug and feature tracker)
+
+Please report any bugs, feature, and/or improvment requests on the
+[Grizzly JIRA][grizzly-jira].
+
+[grizzly-jira]: https://java.net/jira/browse/GRIZZLY
+
+## Clone The Repository
+
+Details on cloning the source repository.  Include info on doing this from
+behind a firewall.  Include info on tags and branches.--- /dev/null
+++ b/site/src/site/markdown/documentation/ajp.md
@@ -0,0 +1,110 @@
+AJP
+===
+
+Overview
+========
+
+Starting with version 2.1, Grizzly supports
+[AJP](http://en.wikipedia.org/wiki/Apache_JServ_Protocol) 1.3 (Apache
+JServ Protocol) natively. "Natively" means AJP is implemented using core
+Grizzly APIs and naturally fits into entire Grizzly infrastructure:
+memory management, threading etc...
+
+How it works
+============
+
+The AJP protocol implementation is mainly represented by two Filters:
+AjpMessageFilter, AjpHandlerFilter. The AjpMessageFilter is responsible
+for constructing AJP protocol messages and AjpHandlerFilter contains the
+actual processing logic, which works as a codec between AJP and HTTP
+messages. All the Filters upstream to AjpHandlerFilter receive HTTP
+messages for processing, so they are not even aware of AJP protocol.
+
+Here is a FilterChain, which is being normally constructed, when Grizzly
+HttpServer being used:
+
+![](../images/ajp/httpserver-filterchain.png)
+
+Now, what happens, if we want to use AJP? It's easy, we replace HTTP
+Filter, which works as a codec for Buffer \<-\> HTTP transformation,
+with the two Filters mentioned above: AjpMessageFilter and
+AjpHandlerFilter:
+
+![](../images/ajp/httpserver-ajp-filterchain.png)
+
+So the Grizzly HttpServer Filter won't even notice it operates over AJP
+rather than plain HTTP.
+
+In order to simplify HttpServer AJP configuration, there is an AjpAddOn
+available, which may be registered on the required HttpServer's
+NetworkListener like:
+
+```java
+HttpServer httpServer = new HttpServer();
+NetworkListener listener =
+         new NetworkListener("grizzly",
+         NetworkListener.DEFAULT_NETWORK_HOST, PORT);
+
+AjpAddOn ajpAddon = new AjpAddOn();
+listener.registerAddOn(ajpAddon);
+
+httpServer.addListener(listener);
+```
+
+AJP Configuration
+=================
+
+<table>
+<caption>AjpHandlerFilter and AjpAddOn Properties</caption>
+<tbody>
+<tr class="odd">
+<td align="left">isTomcatAuthentication</td>
+<td align="left">If set to true, the authentication will be done in Grizzly. 
Otherwise, the authenticated principal will be propagated from the native 
webserver and used for authorization in Grizzly. The default value is 
true.</td>
+</tr>
+<tr class="even">
+<td align="left">secret</td>
+<td align="left">If not null, only requests from workers with this secret 
keyword will be accepted, null means no secret check will be done.</td>
+</tr>
+<tr class="odd">
+<td align="left">shutdownHandlers</td>
+<td align="left">The set of ShutdownHandlers, which will be invoked, when 
AJP shutdown request received. The implementation itself doesn't perform any 
action related to shutdown request.</td>
+</tr>
+</tbody>
+</table>
+
+Sample
+======
+
+There is a simple AJP "Hello World" sample available, which contains a
+single class, single HttpHandler, which is accessable via AJP and HTTP
+at the same time. Here is the most interesting part of it responsible
+for HttpServer initialization.
+
+```java
+final HttpServer server = new HttpServer();
+
+// Create plain HTTP listener, which will handle port 8080
+final NetworkListener httpNetworkListener =
+        new NetworkListener("http-listener", "0.0.0.0", 8080);
+
+// Create AJP listener, which will handle port 8009
+final NetworkListener ajpNetworkListener =
+        new NetworkListener("ajp-listener", "0.0.0.0", 8009);
+// Register AJP addon on HttpServer's listener
+ajpNetworkListener.registerAddOn(new AjpAddOn());
+
+server.addListener(httpNetworkListener);
+server.addListener(ajpNetworkListener);
+
+final ServerConfiguration config = server.getServerConfiguration();
+
+// Map the path, /grizzly, to the HelloWorldHandler
+config.addHttpHandler(new HelloWorldHandler(), "/grizzly");
+```
+
+The
+[readme.txt](http://java.net/projects/grizzly/sources/git/content/samples/http-ajp-samples/readme.txt?rev=c8ff8e24974f3c4be9a1833e58adf139b656a730)
+contains setup and run instructions.
+
+Complete sources and instructions could be found
+[here](http://java.net/projects/grizzly/sources/git/show/samples/http-ajp-samples?rev=c8ff8e24974f3c4be9a1833e58adf139b656a730).---
 /dev/null
+++ b/site/src/site/markdown/documentation/bestpractices.md
@@ -0,0 +1,74 @@
+Best Practices
+==============
+
+When developing a network application, we usually wonder how we can
+optimize it. How should the worker thread pool be sized? Which I/O
+strategy to employ?
+
+There is no general answer for that question, but we'll try to provide
+some tips.
+
+-   **IOStrategy**
+
+    In the [IOStrategy](#iostrategies) section, we introduced different
+    Grizzly IOStrategies.
+
+    By default, Grizzly Transports use the worker-thread IOStrategy,
+    which is reliable for any possible usecase. However, if the
+    application processing logic doesn't involve any blocking I/O
+    operations, the same-thread IOStrategy can be used. For these cases,
+    the same-thread strategy will be more performant as there are no
+    thread context switches.
+
+    For example, if we implement general HTTP Servlet container, we
+    can't be sure about nature of specific Servlets developers may have.
+    In this case it's safter to use the worker-thread IOStrategy.
+    However, if application uses the Grizzly's HttpServer and
+    HttpHandler, which leverages NIO streams, then the same-thread
+    strategy could be used to optimize processing time and resource
+    consumption;
+
+-   **Selector runners count**
+
+    The Grizzly runtime will automatically set the SelectorRunner count
+    value equal to
+    
[Runtime.getRuntime().availableProcessors()](http://download.oracle.com/javase/6/docs/api/java/lang/Runtime.html#availableProcessors()).
+    Depending on the usecase, developers may change this value to better
+    suit their needs.
+
+    Scott Oaks, from the Glassfish performance team,
+    
[suggests](http://weblogs.java.net/blog/2007/12/03/glassfish-tuning-primer)
+    that there should be one SelectorRunner for every 1-4 cores on your
+    machine; no more than that;
+
+-   **Worker thread pool**
+
+    In the [Configuration](#threadpool-config) section, the different
+    thread pool implementations, and their pros and cons, were
+    discussed.
+
+    All IOStrategies, except the same-thread IOStrategy, use worker
+    threads to process IOEvents which occur on Connections. A common
+    question is how many worker threads will be needed by an
+    application?
+
+    In his
+    [blog](http://weblogs.java.net/blog/2007/12/03/glassfish-tuning-primer),
+    Scott suggests How many is "just enough"? It depends, of course --
+    in a case where HTTP requests don't use any external resource and
+    are hence CPU bound, you want only as many HTTP request processing
+    threads as you have CPUs on the machine. But if the HTTP request
+    makes a database call (even indirectly, like by using a JPA entity),
+    the request will block while waiting for the database, and you could
+    profitably run another thread. So this takes some trial and error,
+    but start with the same number of threads as you have CPU and
+    increase them until you no longer see an improvement in throughput.
+
+    Translating this to the general, non HTTP usecase: If IOEvent
+    processing includes blocking I/O operation(s), which will make
+    thread block doing nothing for some time (i.e, waiting for a result
+    from a peer), it's best to have more worker threads to not starve
+    other request processing. For simpler application processes, the
+    fewer threads, the better.
+
+--- /dev/null
+++ b/site/src/site/markdown/documentation/comet.md
@@ -0,0 +1,178 @@
+Comet
+=====
+
+Introduction
+============
+
+From the wikipedia page:
+
+Comet is an umbrella term used to describe a technique allowing web
+browser to receive almost real time updates from the server. The two
+most common approaches are long polling and streaming. Long polling
+differs from streaming in that each update from the server ultimately
+results in another follow up request from the server. With streaming,
+there is one long lived request serving multiple updates. The following
+sections will cover each option with samples of how to implement each
+approach.
+
+Long Polling
+------------
+
+With long polling an initial request is made to the server. This request
+is "parked" waiting for an update. This sleeping request is then
+awakened when an event is called on the CometHandler for the request.
+CometHandler is an interface in the Grizzly framework which an
+application developer implements to register a suspended request with
+the comet system and manage event and lifecyle issues. CometHandler is
+typically where your application logic for your comet-based applications
+lives. The following example shows how to set up a long polling request
+and notify it about events. This code is taken from the count-clicker
+comet sample in the grizzly source repository
+(http://java.net/projects/grizzly/sources/git/show/samples/comet/comet-counter).
+
+```java
+public class CounterHandler extends DefaultCometHandler<HttpServletResponse> 
{
+
+    private HttpServletResponse httpResponse;
+    private AtomicInteger counter;
+
+    CounterHandler(HttpServletResponse httpResponse, final AtomicInteger 
counter) {
+        this.httpResponse = httpResponse;
+        this.counter = counter;
+    }
+
+    public void onEvent(CometEvent event) throws IOException {
+        if (CometEvent.Type.NOTIFY == event.getType()) {
+            httpResponse.addHeader("X-JSON", "{\"counter\":" + counter.get() 
+ " }");
+
+            PrintWriter writer = httpResponse.getWriter();
+            writer.write("success");
+            writer.flush();
+
+            event.getCometContext().resumeCometHandler(this);
+        }
+    }
+
+    public void onInterrupt(CometEvent event) throws IOException {
+        httpResponse.addHeader("X-JSON", "{\"counter\":" + counter.get() + " 
}");
+
+        PrintWriter writer = httpResponse.getWriter();
+        writer.write("success");
+        writer.flush();
+    }
+}
+```
+
+This is the CometHandler for our simple counter application. In this
+simple case, it has an AtomicInteger for tracking count requests and
+return the incremented value for each event. This handler is registered
+in a servlet as shown below.
+
+```java
+public class LongPollingServlet extends HttpServlet {
+
+
+    final AtomicInteger counter = new AtomicInteger();
+    private static final long serialVersionUID = 1L;
+
+    private String contextPath = null;
+
+    @Override
+    public void init(ServletConfig config) throws ServletException {
+        super.init(config);
+
+        ServletContext context = config.getServletContext();
+        contextPath = context.getContextPath() + "/long_polling";
+
+        CometEngine engine = CometEngine.getEngine();
+        CometContext cometContext = engine.register(contextPath);
+        cometContext.setExpirationDelay(5 * 30 * 1000);
+    }
+
+    @Override
+    protected void doGet(HttpServletRequest req, HttpServletResponse res)
+    throws ServletException, IOException {
+        CometEngine engine = CometEngine.getEngine();
+        CometContext<HttpServletResponse> context = 
engine.getCometContext(contextPath);
+        final int hash = context.addCometHandler(new CounterHandler(res, 
counter));
+    }
+
+    @Override
+    protected void doPost(HttpServletRequest req, HttpServletResponse res)
+    throws ServletException, IOException {
+        counter.incrementAndGet();
+        CometContext<HttpServletResponse> context = 
CometEngine.getEngine().getCometContext(contextPath);
+        context.notify(null);
+
+        PrintWriter writer = res.getWriter();
+        writer.write("success");
+        writer.flush();
+    }
+}
+```
+
+The first request comes into doGet() which will create the CometHandler
+and add it to the CometContext. CometContext.addHandler() will suspend
+this request. In the html for the application, there's a link which
+executes a POST against the server which calls doPost(). Here, what
+we're doing is notifying the entire context of an event. This will cause
+onEvent() to be called for each registered CometHandler. That, as we've
+seen, will return the counter value to the browser. After this event is
+processed, the suspended requests will be resumed and eventually
+terminated normally. On the client side, once that GET request is
+terminated, the javascript in the page will submit yet another GET
+request. This request is suspended again as describe above and the
+process can repeat indefinitely. The javascript needed for this is shown
+below:
+
+```java
+var counter = {
+      'poll' : function() {
+         new Ajax.Request('long_polling', {
+            method : 'GET',
+            onSuccess : counter.update
+         });
+      },
+      'increment' : function() {
+         new Ajax.Request('long_polling', {
+            method : 'POST'
+         });
+      },
+      'update' : function(req, json) {
+         $('count').innerHTML = json.counter;
+         counter.poll();
+      }
+}
+```
+
+There are three basic functions involved in this application: poll,
+increment, and update.
+
+1.  poll: This function makes the GET requests to the server which are
+    ultimately suspended. On a successful return from that call,
+    update() is called...
+
+2.  update: This where the page is updated with the results from the
+    server. This function takes the json object returned from the
+    servlet and updates the display accordingly. The last thing it does
+    is call back to poll() which initiates another suspended request.
+
+3.  increment: This function is called whenever you click the link in
+    the application. It initiates the POST request that causes the
+    server state to change and results in the client side updates. There
+    is no handling of the response from this request.
+
+That's all it takes for a simple long polling based application. Long
+polling applications are well suited for handling low frequency events
+from the server such as updates to pages in response to user actions.
+Because of the need for renegotiation of subsequent requests after each
+event, applications with high event frequency are best served by
+streaming applications as we'll see below. Long polling, however, is
+more proxy friendly in many cases. Many proxies balk at seeing
+long-lived connections and might close them according to various
+security or connection timeout policies.
+
+Streaming
+---------
+
+TBD--- /dev/null
+++ b/site/src/site/markdown/documentation/coreconfig.md
@@ -0,0 +1,247 @@
+Core Configuration
+==================
+
+The primary points of configuration of the core framework are that of
+the Transport instances and their associated thread pools. The ability
+to configure both entities is possible via the NIOTransportBuilder.
+
+Transport Configuration
+-----------------------
+
+Just as there are concrete NIOTransport implementations for TCP and UDP,
+so too are there two concrete NIOTransportBuilder implementations. Each
+NIOTransportBuilder implementation exposes configurable features unique
+to each transport. The following describes configuration properties
+common to all NIOTransports and then describes the properties for the
+TCP and UDP NIOTransport implementations.
+
+<table>
+<caption>NIOTransportBuilder Properties</caption>
+<tbody>
+<tr class="odd">
+<td align="left">workerThreadPoolConfig</td>
+<td align="left">This property exposes a ThreadPoolConfig instance that 
allows configuration of the worker thread pool used by the transport that 
will be constructed by this builder. Note: depending on the IOStrategy being 
used, this value may be null.</td>
+</tr>
+<tr class="even">
+<td align="left">selectorThreadPoolConfig</td>
+<td align="left">This propery exposes a ThreadPoolConfig instance that 
allows configuration of the selector/kernel thread pool used by the transport 
that will be constructed by this builder.</td>
+</tr>
+<tr class="odd">
+<td align="left">IOStrategy</td>
+<td align="left">Sets the IOStrategy that will be used by this transport. 
Note that changing this value before the transport has been started may have 
an impact on the return value of the workerThreadPoolConfig property. If no 
value is explicitly set, the WorkerThreadIOStrategy will be employed. See the 
section on <a href="iostrategies.xml">IOStrategies</a> for specifics on each 
concrete IOStrategy included with Grizzly 2.3.</td>
+</tr>
+<tr class="even">
+<td align="left">memoryManager</td>
+<td align="left">Sets the MemoryManager to be used by this transport. If no 
value is explicitly set, the MemoryManager used will be the 
NIOTransportBuilder.DEFAULT_MEMORY_MANAGER. See the section on <a 
href="memory.xml">Memory Management</a> for specifics on the MemoryManager 
system.</td>
+</tr>
+<tr class="odd">
+<td align="left">selectorHandler</td>
+<td align="left">Sets the SelectorHandler to be used by this transport. If 
no value is explicitly set, the SelectorHandler used wil be the 
NIOTransportBuilder.DEFAULT_SELECTOR_HANDLER. See the section on <a 
href="transports-connections.xml">Transports and Connections</a> for 
specifics on the SelectorHandler.</td>
+</tr>
+<tr class="even">
+<td align="left">selectionKeyHandler</td>
+<td align="left">Sets the SelectionKeyHandler to be used by this transport. 
If no value is explicitly set, the SelectionKeyHandler used will be the 
NIOTransportBuilder.DEFAULT_SELECTION_KEY_HANDLER. See the section on <a 
href="transports-connections.xml">Transports and Connections</a> for 
specifics on the SelectionKeyHandler.</td>
+</tr>
+<tr class="odd">
+<td align="left">attributeBuilder</td>
+<td align="left">Sets the AttributeBuilder to be used by this transport. If 
no value is explicitly set, the AttributeBuilder used will be the 
NIOTransportBuilder.DEFAULT_ATTRIBUTE_BUILDER.</td>
+</tr>
+<tr class="even">
+<td align="left">NIOChannelDistributor</td>
+<td align="left">Sets the NIOChannelDistributor used by this transport. See 
the section on <a href="transports-connections.xml?">Transports and 
Connections</a> for specifics on the NIOChannelDistributor.</td>
+</tr>
+<tr class="odd">
+<td align="left">processor</td>
+<td align="left">Sets the Processor used by this transport.</td>
+</tr>
+<tr class="even">
+<td align="left">processorSelector</td>
+<td align="left">Sets the ProcessorSelector used by this transport.</td>
+</tr>
+<tr class="odd">
+<td align="left">readBufferSize</td>
+<td align="left">Sets the size of the Buffer that will be allocated, 
per-connection, to read incoming data.</td>
+</tr>
+<tr class="even">
+<td align="left">writeBuffersSize</td>
+<td align="left">Sets the size of the Buffer that will be applicated, 
per-connection, to write outgoing data.</td>
+</tr>
+</tbody>
+</table>
+
+<table>
+<caption>TCPNIOTransportBuilder Properties</caption>
+<tbody>
+<tr class="odd">
+<td align="left">clientSocketSoTimeout</td>
+<td align="left">Enable/disable SO_TIMEOUT with the specified timeout, in 
milliseconds (client mode).</td>
+</tr>
+<tr class="even">
+<td align="left">connectionTimeout</td>
+<td align="left">Time in milliseconds for how long establishing a connection 
can take before the operation times out.</td>
+</tr>
+<tr class="odd">
+<td align="left">keepAlive</td>
+<td align="left">Enable/disable SO_KEEPALIVE.</td>
+</tr>
+<tr class="even">
+<td align="left">linger</td>
+<td align="left">Enable/disable SO_LINGER with the specified linger time in 
seconds. The maximum timeout value is platform specific. The setting only 
affects socket close.</td>
+</tr>
+<tr class="odd">
+<td align="left">reuseAddress</td>
+<td align="left">Enable/disable the SO_REUSEADDR socket option. When a TCP 
connection is closed the connection may remain in a timeout state for a 
period of time after the connection is closed (typically known as the 
TIME_WAIT state or 2MSL wait state). For applications using a well known 
socket address or port it may not be possible to bind a socket to the 
required SocketAddress if there is a connection in the timeout state 
involving the socket address or port.</td>
+</tr>
+<tr class="even">
+<td align="left">serverConnectionBacklog</td>
+<td align="left">Specifies the maximum pending connection queue length.</td>
+</tr>
+<tr class="odd">
+<td align="left">serverSocketSoTimeout</td>
+<td align="left">Enable/disable SO_TIMEOUT with the specified timeout, in 
milliseconds (server mode).</td>
+</tr>
+<tr class="even">
+<td align="left">tcpNoDelay</td>
+<td align="left">Enable/disable TCP_NODELAY (disable/enable Nagle's 
algorithm).</td>
+</tr>
+<tr class="odd">
+<td align="left">temporarySelectorIO</td>
+<td align="left">Allows the specification of a TemporarySelectorIO instance 
to aid in the simulation of blocking IO.</td>
+</tr>
+<tr class="even">
+<td align="left">optimizedForMultiplexing</td>
+<td align="left">Controlls the behavior of writing to a connection. If 
enabled, then all writes regardless if the current thread can write directly 
to the connection or not, will be passed to the async write queue. When the 
write actually occurs, the transport will attempt to write as much content 
from the write queue as possible. This option is disabled by default.</td>
+</tr>
+<tr class="odd">
+<td align="left">maxAsyncWriteQueueSizeInBytes</td>
+<td align="left">Specifies the size, in bytes, of the async write queue on a 
per-connection basis. If not specified, the value will be configured to be 
four times the size of the system's socket write buffer size. Setting this 
value to -1 will allow the queue to be unbounded.</td>
+</tr>
+</tbody>
+</table>
+
+<table>
+<caption>UDPNIOTransportBuilder Properties</caption>
+<tbody>
+<tr class="odd">
+<td align="left">connectionTimeout</td>
+<td align="left">Time in milliseconds for how long establishing a connection 
can take before the operation times out.</td>
+</tr>
+<tr class="even">
+<td align="left">reuseAddress</td>
+<td align="left">Enable/disable the SO_REUSEADDR socket option. When a TCP 
connection is closed the connection may remain in a timeout state for a 
period of time after the connection is closed (typically known as the 
TIME_WAIT state or 2MSL wait state). For applications using a well known 
socket address or port it may not be possible to bind a socket to the 
required SocketAddress if there is a connection in the timeout state 
involving the socket address or port.</td>
+</tr>
+<tr class="odd">
+<td align="left">temporarySelectorIO</td>
+<td align="left">Allows the specification of a TemporarySelectorIO instance 
to aid in the simulation of blocking IO.</td>
+</tr>
+</tbody>
+</table>
+
+Thread Pool Configuration
+-------------------------
+
+Grizzly's thread pool configuration is managed by the ThreadPoolConfig
+object:
+
+<table>
+<caption>ThreadPoolConfig Properties</caption>
+<tbody>
+<tr class="odd">
+<td align="left">queue</td>
+<td align="left">The task Queue implementation to be used.</td>
+</tr>
+<tr class="even">
+<td align="left">queueLimit</td>
+<td align="left">The maximum number of pending tasks that may be queued.</td>
+</tr>
+<tr class="odd">
+<td align="left">threadFactory</td>
+<td align="left">The ThreadFactory that the pool will use to create new 
Threads.</td>
+</tr>
+<tr class="even">
+<td align="left">poolName</td>
+<td align="left">The name of this thread pool.</td>
+</tr>
+<tr class="odd">
+<td align="left">priority</td>
+<td align="left">The priority to be assigned to each thread. This will 
override any priority assigned by the specified ThreadFactory.</td>
+</tr>
+<tr class="even">
+<td align="left">corePoolSize</td>
+<td align="left">The initial number of threads that will be present with the 
thread pool is created.</td>
+</tr>
+<tr class="odd">
+<td align="left">maxPoolSize</td>
+<td align="left">The maximum number threads that may be maintained by this 
thread pool.</td>
+</tr>
+<tr class="even">
+<td align="left">keepAliveTime</td>
+<td align="left">The maximum time a thread may stay idle and wait for a new 
task to execute before it will be released. Custom time units can be 
used.</td>
+</tr>
+<tr class="odd">
+<td align="left">transactionTimeout</td>
+<td align="left">The maximum time a thread may be allowed to run a single 
task before interrupt signal will be sent. Custom time units can be used.</td>
+</tr>
+</tbody>
+</table>
+
+The thread pool configuration is fairly straight forward. However, it
+should be noted that Grizzly, internally, has several thread pool
+implementations: SyncThreadPool, FixedThreadPool, and
+QueueLimitedThreadPool. Which implementation is chosen is based on the
+configuration. The following sections describe each of the thread pool
+implementations.
+
+### FixedThreadPool
+
+This pool will be selected when the queueLimit property is less than
+zero, and the max and core pool sizes are the same. The FixedThreadPool
+has no synchronization when executing tasks, so it offers better
+performance.
+
+### QueueLimitedThreadPool
+
+This pool will be selected when the queueLimit property is greater than
+zero, and the max and core pool sizes are the same. The
+QueueLimitedThreadPool is an extension of the FixedThreadPool, so if
+offers the same benefits of the FixedThreadPool without having an
+unbounded task queue.
+
+### SyncThreadPool
+
+This pool will be selected when none of the criteria for the other
+thread pools apply. This thread pool does have synchronization to have
+precise control over the decision of thread creation.
+
+Examples
+--------
+
+Here are some examples of using the TCPNIOTransportBuilder to configure
+the Transport and/or thread pool.
+
+```java
+final TCPNIOTransportBuilder builder = TCPNIOTranportBuilder.newInstance();
+final TCPNIOTransport transport = builder.build();
+```
+
+Creates a new TCPNIOTransport using all default configuration values.
+
+```java
+final TCPNIOTransportBuilder builder = TCPNIOTransportBuilder.newInstance();
+final TCPNIOTransport transport = 
builder.setIOStrategy(SameThreadIOStrategy.getInstance()).setTcpNoDelay(true).build();
+```
+
+Creates a new TCPNIOTransport instance using the SameThreadIOStrategy,
+and tcp-no-delay set to true. Note that configuration calls can be
+chained.
+
+```java
+final TCPNIOTransportBuilder builder = TCPNIOTransportBuilder.newInstance();
+final ThreadPoolConfig config = builder.getWorkerThreadPoolConfig();
+config.setCorePoolSize(5).setMaxPoolSize(5).setQueueLimit(-1);
+final TCPNIOTransport transport = builder.build();
+```
+
+This example will configure the TCPNIOTransport to use the
+FixedThreadPool implementation due to the fact that there is no queue
+limit and the core and max pool sizes are the same.--- /dev/null
+++ b/site/src/site/markdown/documentation/coreframeworksamples.md
@@ -0,0 +1,221 @@
+Samples
+=======
+
+Parsing an incoming message
+---------------------------
+
+When writing network application, very often we need to parse incoming
+bytes into application specific message.
+
+The problem is that chunk of data been read from NIO Connection may
+contain just a part of application message, or contain several of them
+at once. So how parsing Filter should work out these scenarious?
+
+-   If we don't have enough data to build an application message - we
+    stop the FilterChain processing and store the incomplete buffer by
+    returning
+
+```java
+return filterChainContext.getStopAction(buffer);
+```
+
+-   If the source Buffer contains more than one message at once - we're
+    splitting up the source Buffer into two chunks:
+
+    1.  The Buffer, which belongs to the first complete application
+        message;
+
+    2.  The remainder.
+
+    The 1st chunk could be parsed immediately and correspondent
+    application message created. After completing the parsing we may
+    want to instruct FilterChain to continue execution, by calling the
+    next Filter in the chain, and store the remainder to be processed
+    later (once processing of this message is complete).
+
+```java
+return filterChainContext.getInvokeAction(remainder);
+```
+
+Here is an example of parsing Filter, parses the incoming Buffer and
+creates a GIOPMessage, which has following structure
+
+```java
+public class GIOPMessage {
+    private byte G;
+    private byte I;
+    private byte O;
+    private byte P;
+
+    private byte major;
+    private byte minor;
+
+    private byte flags;
+    private byte value;
+
+    private int bodyLength;
+
+    private byte[] body;
+}
+```
+
+So the actual parser Filter code is
+
+```java
+private static final int HEADER_SIZE = 12;
+
+/**
+ * Method is called, when new data was read from the Connection and ready
+ * to be processed.
+ *
+ * We override this method to perform Buffer -> GIOPMessage transformation.
+ *
+ * @param ctx Context of {@link FilterChainContext} processing
+ * @return the next action
+ * @throws java.io.IOException
+ */
+@Override
+public NextAction handleRead(final FilterChainContext ctx) throws 
IOException {
+    // Get the source buffer from the context
+    final Buffer sourceBuffer = ctx.getMessage();
+
+    final int sourceBufferLength = sourceBuffer.remaining();
+
+    // If source buffer doesn't contain header
+    if (sourceBufferLength < HEADER_SIZE) {
+        // stop the filterchain processing and store sourceBuffer to be
+        // used next time
+
+    }
+
+    // Get the body length
+    final int bodyLength = sourceBuffer.getInt(HEADER_SIZE - 4);
+    // The complete message length
+    final int completeMessageLength = HEADER_SIZE + bodyLength;
+
+    // If the source message doesn't contain entire body
+    if (sourceBufferLength < completeMessageLength) {
+        // stop the filterchain processing and store sourceBuffer to be
+        // used next time
+
+    }
+
+    // Check if the source buffer has more than 1 complete GIOP message
+    // If yes - split up the first message and the remainder
+    final Buffer remainder = sourceBufferLength > completeMessageLength ?
+        sourceBuffer.split(completeMessageLength) : null;
+
+    // Construct a GIOP message
+    final GIOPMessage giopMessage = new GIOPMessage();
+
+    // Set GIOP header bytes
+    giopMessage.setGIOPHeader(sourceBuffer.get(), sourceBuffer.get(),
+            sourceBuffer.get(), sourceBuffer.get());
+
+    // Set major version
+    giopMessage.setMajor(sourceBuffer.get());
+
+    // Set minor version
+    giopMessage.setMinor(sourceBuffer.get());
+
+    // Set flags
+    giopMessage.setFlags(sourceBuffer.get());
+
+    // Set value
+    giopMessage.setValue(sourceBuffer.get());
+
+    // Set body length
+    giopMessage.setBodyLength(sourceBuffer.getInt());
+
+    // Read body
+    final byte[] body = new byte[bodyLength];
+    sourceBuffer.get(body);
+    // Set body
+    giopMessage.setBody(body);
+
+    ctx.setMessage(giopMessage);
+
+    // We can try to dispose the buffer
+    sourceBuffer.tryDispose();
+
+    // Instruct FilterChain to store the remainder (if any) and continue 
execution
+
+}
+```
+
+Asynchronous FilterChain execution
+----------------------------------
+
+During the FilterChain execution, we might want to continue IOEvent
+processing in the different/custom thread.
+
+For example, we've chosen the SameThreadStrategy for our usecase to
+avoid redundant thread context switches and it fits great to our
+usecase, but at the same time we still have some scenarious, which
+either execute long lasting tasks, or use blocking I/O (for ex. database
+access), and to not make entire server unresponsive, we'd want to
+execute such a task in our custom thread pool and let Grizzly service
+other Connections.
+
+This might be easily implemented with Grizzly using code like (not
+working sample):
+
+```java
+public NextAction handleRead(final FilterChainContext ctx) throws 
IOException {
+
+        // Get the SuspendAction in advance, cause once we execute 
LongLastTask in the
+        // custom thread - we lose control over the context
+        final NextAction suspendAction = ctx.getSuspendAction();
+
+        // suspend the current execution
+        ctx.suspend();
+
+        // schedule async work
+        scheduler.schedule(new Runnable() {
+
+            @Override
+            public void run() {
+                doLongLastingTask();
+
+                // Resume the FilterChain IOEvent processing
+                ctx.resumeNext();
+            }
+        }, 5, TimeUnit.SECONDS);
+
+        // return suspend status
+        return suspendAction;
+}
+```
+
+during processing IOEvent. We have to understand that by instructing
+Grizzly to suspend the IOEvent execution, we're becoming responsible for
+resuming the execution at one point of time (when long lasting task or
+blocking I/O operation completes).
+
+```java
+public void run() {
+    doLongLastingTask();
+
+    // Resume the FilterChain IOEvent processing
+    ctx.resumeNext();
+}
+```
+
+Other samples
+-------------
+
+The core framwork samples can be reviewed in one of two ways:
+
+-   Directly from the git repository:
+
+```
+git clone git://java.net/grizzly~git
+cd grizzly~git
+git checkout 2_3
+cd samples/framework-samples
+```
+
+-   Download the sample source bundle from:
+    
<https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/samples/grizzly-framework-samples/2.3/grizzly-framework-samples-2.3-sources.jar>
+
+--- /dev/null
+++ b/site/src/site/markdown/documentation/dependencies.md
@@ -0,0 +1,222 @@
+Dependencies
+============
+
+Grizzly is built, assembled and installed using Maven. Grizzly is
+deployed to the Maven Central repository at the following location:
+<http://repo1.maven.org/>. Jars, Jar sources, Jar JavaDoc and samples
+are all available on the Maven Central repository.
+
+An application depending on Grizzly requires that it in turn includes
+the set of jars that Grizzly depends on. Grizzly has a pluggable
+component architecture so the set of jars required to be include in the
+class path can be different for each application.
+
+All Grizzly components are built using Java SE 6 compiler. It means, you
+will also need at least Java SE 6 to be able to compile and run your
+application.
+
+Developers using maven are likely to find it easier to include and
+manage dependencies of their applications than developers using ant or
+other build technologies. This document will explain to both maven and
+non-maven developers how to depend on Jersey for their application. Ant
+developers are likely to find the Ant Tasks for Maven very useful.
+
+In general, if you're not using Maven, most probably you'd need to
+download dependencies (jar files) directly from the Maven repository.
+
+Grizzly's runtime dependencies are categorized into the following:
+
+-   Core framework. The Grizzly core module. The rest of Grizzly modules
+    depend on it;
+
+-   HTTP framework. The HTTP Codec implementation;
+
+-   HTTP Server framework. Grizzly HTTP server implementation;
+
+-   HTTP Servlet framework. Basic Grizzly based Servlet support;
+
+-   Port unification;
+
+-   Comet;
+
+-   WebSockets;
+
+-   AJP;
+
+-   JAX-WS.
+
+Core framework
+==============
+
+Maven developers require a dependency on the grizzly core module. The
+following dependency needs to be added to the pom:
+
+```xml
+<dependency>
+    <groupId>org.glassfish.grizzly</groupId>
+    <artifactId>grizzly-framework</artifactId>
+    <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers require:
+
+-   
[grizzly-framework.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-framework/2.3/grizzly-framework-2.3.jar)
+
+-   
[gmbal-api-only.jar](http://download.java.net/maven/2/org/glassfish/gmbal/gmbal-api-only/3.0.0-b023/gmbal-api-only-3.0.0-b023.jar)
+
+HTTP framework
+==============
+
+Maven developers require a dependency on the http module. The following
+dependency needs to be added to the pom:
+
+```xml
+<dependency>
+     <groupId>org.glassfish.grizzly</groupId>
+     <artifactId>grizzly-http</artifactId>
+     <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers additionally to jars, required by [Core
+framework](#core-dep), require:
+
+-   
[grizzly-http.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-http/2.3/grizzly-http-2.3.jar)
+
+HTTP Server framework
+=====================
+
+Maven developers require a dependency on the http-server module. The
+following dependency needs to be added to the pom:
+
+```xml
+<dependency>
+     <groupId>org.glassfish.grizzly</groupId>
+     <artifactId>grizzly-http-server</artifactId>
+     <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers, additionally to jars, required by [HTTP
+framework](#http-dep), require:
+
+-   
[grizzly-http-server.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-http-server/2.3/grizzly-http-server-2.3.jar)
+
+HTTP Servlet framework
+======================
+
+Maven developers require a dependency on the http-servlet module. The
+following dependency needs to be added to the pom:
+
+```xml
+<dependency>
+     <groupId>org.glassfish.grizzly</groupId>
+     <artifactId>grizzly-http-servlet</artifactId>
+     <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers, additionally to jars, required by [HTTP Server
+framework](#http-server-dep), require:
+
+-   
[grizzly-http-servlet.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-http-servlet/2.3/grizzly-http-servlet-2.3.jar)
+
+-   
[servlet-api.jar](http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar)
+
+Port unification
+================
+
+Maven developers require a dependency on the portunif module. The
+following dependency needs to be added to the pom:
+
+```xml
+<dependency>
+     <groupId>org.glassfish.grizzly</groupId>
+     <artifactId>grizzly-portunif</artifactId>
+     <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers, additionally to jars, required by [Core
+framework](#core-dep), require:
+
+-   
[grizzly-portunif.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-portunif/2.3/grizzly-portunif-2.3.jar)
+
+Comet
+=====
+
+Maven developers require a dependency on the http-comet module. The
+following dependency needs to be added to the pom:
+
+```xml
+<dependency>
+     <groupId>org.glassfish.grizzly</groupId>
+     <artifactId>grizzly-comet</artifactId>
+     <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers, additionally to jars, required by [HTTP Server
+framework](#http-server-dep), require:
+
+-   
[grizzly-comet.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-comet/2.3/grizzly-comet-2.3.jar)
+
+WebSockets
+==========
+
+Maven developers require a dependency on the websockets module. The
+following dependency needs to be added to the pom:
+
+```xml
+<dependency>
+     <groupId>org.glassfish.grizzly</groupId>
+     <artifactId>grizzly-websockets</artifactId>
+     <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers, additionally to jars, required by [HTTP Server
+framework](#http-server-dep), require:
+
+-   
[grizzly-websockets.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-websockets/2.3/grizzly-websockets-2.3.jar)
+
+AJP
+===
+
+Maven developers require a dependency on the ajp module. The following
+dependency needs to be added to the pom:
+
+```xml
+<dependency>
+     <groupId>org.glassfish.grizzly</groupId>
+     <artifactId>grizzly-http-ajp</artifactId>
+     <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers, additionally to jars, required by [HTTP Server
+framework](#http-server-dep), require:
+
+-   
[grizzly-http-ajp.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-http-ajp/2.3/grizzly-http-ajp-2.3.jar)
+
+JAX-WS
+======
+
+Maven developers require a dependency on the Grizzly jax-ws module. The
+following dependency needs to be added to the pom:
+
+```xml
+<dependency>
+     <groupId>org.glassfish.grizzly</groupId>
+     <artifactId>grizzly-http-server-jaxws</artifactId>
+     <version>2.3</version>
+</dependency>
+```
+
+Non-maven developers, additionally to jars, required by [HTTP Server
+framework](#http-server-dep), require:
+
+-   
[grizzly-http-server-jaxws.jar](https://maven.java.net/content/repositories/releases/org/glassfish/grizzly/grizzly-http-server-jaxws/2.3/grizzly-http-server-jaxws-2.3.jar)
+
+--- /dev/null
+++ b/site/src/site/markdown/documentation/filterchainfilters.md
@@ -0,0 +1,360 @@
+FilterChain and Filters
+=======================
+
+In the previous sections we mentioned the *Processor*, and its role -
+processing I/O events occurred on Grizzly *Connection*s. The
+*FilterChain* is the most useful type of *Processor* used in Grizzly.
+
+![](../images/coreframework/filterchain-diagram.png)
+
+*FilterChain*, according to its name, is a chain of *Filter*s. Each
+*Filter* represents a unit of processing work to be performed, whose
+purpose is to examine and/or modify the state of the transaction that is
+represented by a *FilterChainContext*.
+
+To give an idea how *FilterChain* may look like, here is example of
+*FilterChain*, which implements HTTP server logic:
+
+![](../images/coreframework/http-filterchain.png)
+
+-   TransportFilter is responsible to read data from network
+    *Connection* to a *Buffer*, and to write data from *Buffer* to a
+    nework *Connection*
+
+-   HttpFilter is responsible for *Buffer* \<-\> *HttpPacket*
+    transformation (both directions)
+
+-   HttpServerFilter is responsible for processing request *HttpPacket*s
+    and generating response *HttpPacket*s and send them back on
+    *FilterChain* in opposite direction
+    (HttpServerFilter-\>HttpFilter-\>TransportFilter).
+
+So, what if we want to implement HTTPS server? It's simple:
+
+![](../images/coreframework/https-filterchain.png)
+
+we add just one SSLFilter, responsible for encoding/decoding SSL secured
+data.
+
+As we see, during the processing of any I/O Event, Filters in a
+FilterChain will be executed in the certain order. **It's important to
+remember that the most of I/O Events are processed starting from first
+filter to last (from left to right on the schema above), except WRITE
+event, whose processing starts from last Filter in chain to first (from
+right to left a the schema above).**
+
+Let's define some **terminology** to make the following descriptions
+clearer:
+
+-   **Upstream** - direction from this Filter to the last Filter in
+    chain (from left to right on the schema above);
+
+-   **Downstream** - direction from this Filter to the first Filter in
+    chain (from right to left on the schema above);
+
+Let's take a look which I/O events could be processed by a
+*FilterChain*, for that purpose we can just take a look at the *Filter*
+interface methods:
+
+```java
+public NextAction handleRead(FilterChainContext ctx) throws IOException;
+
+public NextAction handleWrite(FilterChainContext ctx) throws IOException;
+
+public NextAction handleConnect(FilterChainContext ctx) throws IOException;
+
+public NextAction handleAccept(FilterChainContext ctx) throws IOException;
+
+public NextAction handleClose(FilterChainContext ctx) throws IOException;
+```
+
+so I/O events are
+
+-   READ: data is available from a Connection, which could be read and
+    processed;
+
+-   WRITE: data is going to be written to a Connection and the Filter
+    might be responsible to transform data representation form, like
+    *HttpPacket* -\> *Buffer* on schema above;
+
+-   CONNECT: new client *Connection* has been connected;
+
+-   ACCEPT (TCP only): new client *Connection* has been accepted by
+    server *Connection* (*TCPNIOServerConnection*);
+
+-   CLOSE: the Connection has been closed (either locally or by peer);
+
+**It's important to remember that the same I/O events on the specific
+Connection are processed serially. For example, if we process READ I/O
+event on Connection "A", Grizzly will never start processing another
+READ I/O event on the same Connection "A" until the processing of the
+previous READ I/O event has completed processing. If the user decides to
+take ownership of I/O event processing, then the "rule" of serial event
+processing should still be observed.**
+
+Additionally FilterChain Filters are able to initiate and handle custom
+event notifications. The event initiator may choose to emit the event
+upstream or downstream by FilterChain like:
+
+```java
+public NextAction handleRead(FilterChainContext ctx) throws IOException {
+        // Here we decide to notify downstream Filters
+        ctx.notifyDownstream(new OneEvent(...));
+
+        // Notify upstream Filters
+        ctx.notifyUpstream(new AnotherEvent(...));
+}
+```
+
+The Filters in FilterChain are able to intercept and process custom
+Events by implementing method:
+
+```java
+public NextAction handleEvent(FilterChainContext ctx, FilterChainEvent 
event) throws IOException;
+```
+
+As we see each Filter "handle" method has FilterChainContext parameter
+and returns NextAction result.
+
+-   **FilterChainContext**
+
+    ![](../images/coreframework/filterchaincontext.png)
+
+    FilterChainContext represents a context (state), associated with
+    processing of specific I/O event on the specific Connection, so its
+    lifecycle is bound to the processing of a single I/O event.
+
+    FilterChainContext contains following state information:
+
+    -   **Connection**
+
+        The Connection I/O event occurred on;
+
+    -   **Address**
+
+        The peer address. In most cases it returns the same value as
+        *Connection.getPeerAddress()*, except in the case when we handle
+        a READ event on unbound UDP Connection. In this case, the
+        *FilterChainContext.getAddress()* will return the address of
+        peer, which sent data;
+
+    -   **Message**
+
+        The message being processed. This is the only value Filters may
+        change during the I/O event processing. Usually it is used
+        during the incoming/outgoing message parsing/serializing. Each
+        Filter is able to take initial message data, transform it to a
+        different representation, set it back and pass processing to the
+        next Filter in chain.
+
+        For example, when handling READ event, HttpFilter gets message
+        from FilterChainContext as Grizzly Buffer, transforms it to a
+        HttpPacket, sets HttpPacket back to FilterChainContext message
+        and passes control to a HttpServerFilter, which will get
+        HttpPacket from the FilterChainContext and process it.
+
+    In addition to holding the state, the FilterChainContext provides
+    support for commonly used I/O operations:
+
+    -   **Read**
+
+            ReadResult readResult = ctx.read();
+
+        This operation performs a blocking FilterChain read starting at
+        the first Filter in chain (inclusive) upstream to this Filter
+        (exlusive).
+
+        The operation will return a result, when processing of READ I/O
+        event will reach the current Filter and FilterChain will be
+        about to call handleRead(...) operation of this Filter.
+
+    -   **Write**
+
+            `ctx.write(message);`
+
+            or
+
+            `ctx.write(message, completionHandler);`
+
+            or
+
+            `ctx.write(address, message, completionHandler);  // Unbound UDP 
only`
+
+        This operation performs a non-blocking FilterChain write
+        starting at this Filter (exclusive) downstream to the first
+        Filter (inclusive). This operation initiates processing of WRITE
+        I/O event on the FilterChain starting from this Filter
+        (exclusive).
+
+    -   **Flush**
+
+            `ctx.flush();`
+
+            or
+
+            `ctx.flush(completionHandler);`
+
+        This operation initializes and notifies downstream filters about
+        special *TransportFilter.FlushEvent* so each Filter is able to
+        handle this event and make sure all the cached data was written
+        on the Connection.
+
+    -   **Event notification**
+
+            `ctx.notifyUpstream(event);`
+
+            or
+
+    
[truncated due to length]



[grizzly~git:a3441750] [2.3.x] Checkpoint of site work.

rlubke 04/24/2013
Terms of Use; Privacy Policy; Copyright ©2013-2017 (revision 20160708.bf2ac18)
 
 
Close
loading
Please Confirm
Close