FilterChainContext
FilterChainContext代表一个context（state），与特定连接上的处理的特定I/O事件有关，因此其生命周期是绑定到单个I/O事件处理上的。 FilterChainContext包含以下状态信息： Connection
Connection I/O事件发生的地方 Address
The peer address。大多数情况下返回相同的值，Connection.getPeerAddress()，除了在未绑定的UDP Connection上处理READ事件时。此时，FilterChainContext.getAddress将返回发送数据的peer的地址。 Message
被处理的消息。这是在I/O事件处理期间Filters唯一可以改变的值。Usually it is used during the incoming/outgoing message parsing/serializing. 每个Filter都可以将初始的消息数据转换为不同的表现形式，设置回去，然后传递到下一个Filter进行处理。
例如，当处理READ事件时，HttpFilter从FilterChainContext得到Grizzly Buffer形式的消息数据，转换为HttpPacket，将HttpPacket设置回FilterChainContext消息中，然后将控制传递给HttpServerFilter，HttpServerFilter将从FilterChainContext得到HttpPacket，并进行处理。
除了保持状态之外，FilterChainContext还支持常用的I/O操作： Read
ReadResultreadResult = ctx.read();
This operation performs a blocking FilterChain read starting at the first Filter in chain (包含) upstream to this Filter (不含).从第一个Filter到当前Filter的阻塞读。
当READ I/O事件处理到达本Filter，FilterChain将调用本Filter的handleRead(…)方法，然后返回一个结果。 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 (不含) downstream to the first Filter (包含). 从本Filter到第一个Filter的非阻塞写。
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
ctx.notifyDownstream(event);
This operation notifies all the upstream/downstream Filters in the FilterChain about specific FilterChainEvent.
NextAction
如上所述，在一个I/O事件处理期间，FilterChain依次调用Filters，从第一个到最后一个，WRITE事件除外。WRITE事件是从最后一个到第一个。同时Filters可以改变默认的I/O 事件处理顺序，通过返回不同的NextAction类型。 StopAction
returnctx.getStopAction();
告知FilterChain停止处理当前I/O事件。通常当没有足够数据继续进行FilterChain处理时返回StopAction，或者是最后一个Filter。 StopAction可以加参数:
returnctx.getStopAction(incompleteChunk);
or
returnctx.getStopAction(incompleteChunk, appender);
StopAction中的incompleteChunk意味着没有足够的数据继续FilterChain处理。As more data becomes available but before FilterChain calls the Filter, it will check if the Filter has any data stored after the last invocation. If an incompleteChunk is present it will append the new data to the stored one and pass the result as the FilterChainContext message.
注意： theincompleteChunk should be “appendable”, so the FilterChain will know how new data chunk should be appended to the stored one. So the incompleteChunk should either implement org.glassfish.grizzly.Appendable or org.glassfish.grizzly.Appender should be passed as additional parameter. InvokeAction
returnctx.getInvokeAction();
告知FilterChain执行下一个Filter，按照自然执行顺序。
也可以创建带有incompleteChunk 参数的InvokeAction:
returnctx.getInvokeAction(incompleteChunk, appender);
this instructs the FilterChain to store the incompleteChunk and continue FilterChain execution like it was with non-parameterized version.
该特性主要适用这些场景：从source Buffer中解析出来的一个或多个消息，然后发现有一个remainer，没有足够的数据转换为应用消息。因此开发者可以带着这些解析后的消息继续FilterChain处理，保存incompleteChunk remainder。As more data becomes available but before FilterChain calls the Filter again, it will check if the Filter has any data stored after the last invocation. If an incompleteChunk is present it will append the new data to the stored one and pass the result as the FilterChainContext message.
注意： theincompleteChunk should be “appendable”, so the FilterChain will know how new data chunk should be appended to the stored one. So the incompleteChunk should either implement org.glassfish.grizzly.Appendable or org.glassfish.grizzly.Appender should be passed as additional parameter.
另一个选择是创建一个带有unparsedChunk 参数的InvokeAction： returnctx.getInvokeAction(unparsedChunk);
告知FilterChain保存unparsedChunk，然后像不带参数的版本那样继续FilterChain执行。与“incompleteChunk”不同的是，这次我们不知道unparsedChunk是否有足够的数据，以转换成应用消息。一旦FilterChain执行结束，the unparsedChunk of the most recent Filter in chain will be restored FilterChain processing will be re-initialed immediately starting from the Filter which stored the unparsedChunk.
该特性主要适用这些场景：从source Buffer中解析出来的消息，然后发现Buffer有一个
remainer，这可能包含/不包含更多消息。开发者可以提取第一个消息，保存remainder，等当前消息处理完毕，再进行处理 RerunFilterAction
returnctx.getRerunFilterAction();
告知FilterChain重新运行一次本Filter。这对简化I/O事件处理编码和避免递归非常有用。 SuspendAction
returnctx.getSuspendAction();
告知FilterChain挂起(离开)当前线程中的I/O事件处理。可以通过调用以下方法继续I/O事
件处理：
* ctx.resume()：在挂起的Filter中继续执行
* ctx.resume(NextAction)：在挂起的Filter中继续执行，但不是把控制给该
Filter， - it simulates the Filter processing completion like if it returned NextAction as the result
* ctx.resumeNext()：在挂起的下一个Filter中继续执行。Same as
ctx.resume(ctx.getInvokeAction()).
注意：在返回SuspendAction之后，I/O事件处理继续之前，Grizzly不会再同一个Connection上开始处理相同的I/O事件。例如如果在READ 事件处理期间返回SuspendAction–在同一个Connection上进来任何数据，Grizzly都将不会通知FilterChain，直到挂起事件的READ事件完成。
ForkAction (was SuspendStopAction) returnctx.getForkAction();
跟SuspendAction很像，只有一点不同。在得到ForkAction之后，Grizzly会保持监听连接上的相同I/O事件，一旦发生就将通知FilterChain。 注意：ensure that two or more threads are not processing the same I/O operation simultaneously.确保多个线程不会同时处理相同的I/O操作。
1.5 Core Configuration
1.6 Port Unification
1.7 Monitoring
1.8 Best Practices
1.9 Quick Start
1.10 Samples
二、HTTP Components
2.1 Core HTTP Framework
2.2 HTTP Server Framework
2.3 HTTP Server Framework Extras
2.4 Comet
2.5 JAXWS
2.6 WebSockets
2.7 AJP
2.8 SPDY
