Chapter 6. ChannelHandler and ChannelPipeline
This chapter covers
- The ChannelHandler and ChannelPipeline APIs
- Detecting resource leaks
- Exception handling
In the previous chapter you studied ByteBuf, Netty’s data container. As we explore Netty’s dataflow and processing components in this chapter, we’ll build on what you’ve learned and you’ll begin to see important elements of the framework coming together.
You already know that ChannelHandlers can be chained together in a ChannelPipeline to organize processing logic. We’ll examine a variety of use cases involving these classes and an important relation, ChannelHandlerContext.
Understanding the interactions among all of these components is essential to building modular, reusable implementations with Netty.
To prepare for our detailed study of ChannelHandler, we’ll spend time on some of the underpinnings of this part of Netty’s component model.
Interface Channel defines a simple but powerful state model that’s closely related to the ChannelInboundHandler API. The four Channel states are listed in table 6.1.
Table 6.1. Channel lifecycle states
| State |
Description |
|---|---|
| ChannelUnregistered | The Channel was created, but isn’t registered to an EventLoop. |
| ChannelRegistered | The Channel is registered to an EventLoop. |
| ChannelActive | The Channel is active (connected to its remote peer). It’s now possible to receive and send data. |
| ChannelInactive | The Channel isn’t connected to the remote peer. |