Interface ChannelUpstreamHandler

All Superinterfaces:
ChannelHandler
All Known Implementing Classes:
AbstractCodecEmbedder.EmbeddedChannelSink, AbstractTrafficShapingHandler, AutobahnServerHandler, Base64Decoder, BigIntegerDecoder, BlockingReadHandler, BufferedWriteHandler, ChannelTrafficShapingHandler, ChunkedWriteHandler, CompatibleMarshallingDecoder, DelimiterBasedFrameDecoder, DiscardClientHandler, DiscardServerHandler, EchoClientHandler, EchoServerHandler, ExecutionHandler, FactorialClientHandler, FactorialServerHandler, FixedLengthFrameDecoder, FrameDecoder, GlobalChannelTrafficShapingHandler, GlobalTrafficShapingHandler, HexDumpProxyInboundHandler, HexDumpProxyInboundHandler.OutboundHandler, HttpChunkAggregator, HttpClientCodec, HttpClientCodec.Decoder, HttpContentCompressor, HttpContentDecoder, HttpContentDecompressor, HttpContentEncoder, HttpHelloWorldServerHandler, HttpMessageDecoder, HttpRequestDecoder, HttpResponseDecoder, HttpServerCodec, HttpSnoopClientHandler, HttpSnoopServerHandler, HttpStaticFileServerHandler, HttpTunnelingClientSocketChannel.ServletChannelHandler, HttpTunnelingServlet.OutboundConnectionHandler, HttpUploadClientHandler, HttpUploadServerHandler, IdleStateAwareChannelHandler, IdleStateAwareChannelUpstreamHandler, IdleStateHandler, IpFilteringHandlerImpl, IpFilterRuleHandler, LengthFieldBasedFrameDecoder, LineBasedFrameDecoder, LocalTimeClientHandler, LocalTimeServerHandler, LoggingHandler, MarshallingDecoder, ObjectDecoder, ObjectEchoClientHandler, ObjectEchoServerHandler, OneIpFilterHandler, OneToOneDecoder, PortUnificationServerHandler, ProtobufDecoder, ProtobufVarint32FrameDecoder, QuoteOfTheMomentClientHandler, QuoteOfTheMomentServerHandler, ReadTimeoutHandler, ReplayingDecoder, RtspMessageDecoder, RtspRequestDecoder, RtspResponseDecoder, SecureChatClientHandler, SecureChatServerHandler, ServerBootstrap.Binder, SimpleChannelHandler, SimpleChannelUpstreamHandler, SocksAuthRequestDecoder, SocksAuthResponseDecoder, SocksCmdRequestDecoder, SocksCmdResponseDecoder, SocksInitRequestDecoder, SocksInitResponseDecoder, SpdyFrameCodec, SpdyHttpCodec, SpdyHttpDecoder, SpdyHttpResponseStreamIdHandler, SpdyOrHttpChooser, SpdySessionHandler, SslHandler, StringDecoder, TelnetClientHandler, TelnetServerHandler, UptimeClientHandler, WebSocket00FrameDecoder, WebSocket07FrameDecoder, WebSocket08FrameDecoder, WebSocket13FrameDecoder, WebSocketClientHandler, WebSocketFrameAggregator, WebSocketServerHandler, WebSocketServerProtocolHandler, WebSocketServerProtocolHandshakeHandler, ZlibDecoder

public interface ChannelUpstreamHandler extends ChannelHandler
Handles or intercepts an upstream ChannelEvent, and sends a ChannelEvent to the next handler in a ChannelPipeline.

The most common use case of this interface is to intercept an I/O event generated by I/O workers to transform the received messages or execute the relevant business logic.

SimpleChannelUpstreamHandler

In most cases, you will get to use a SimpleChannelUpstreamHandler to implement an upstream handler because it provides an individual handler method for each event type. You might want to implement this interface directly though if you want to handle various types of events in more generic way.

Firing an event to the next handler

You can forward the received event upstream or downstream. In most cases, ChannelUpstreamHandler will send the event upstream (i.e. inbound) although it is legal to send the event downstream (i.e. outbound):

 // Sending the event upstream (inbound)
 void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
     ...
     ctx.sendUpstream(e);
     ...
 }

 // Sending the event downstream (outbound)
 void handleDownstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
     ...
     ctx.sendDownstream(new DownstreamMessageEvent(...));
     ...
 }
 

Using the helper class to send an event

You will also find various helper methods in Channels to be useful to generate and send an artificial or manipulated event.

State management

Please refer to ChannelHandler.

Thread safety

handleUpstream will be invoked sequentially by the same thread (i.e. an I/O thread) and therefore a handler does not need to worry about being invoked with a new upstream event before the previous upstream event is finished.

This does not necessarily mean that there's a dedicated thread per Channel; the I/O thread of some transport can serve more than one Channel (e.g. NIO transport), while the I/O thread of other transports can serve only one (e.g. OIO transport).

However, if you add an ExecutionHandler to a ChannelPipeline, this behavior changes depending on what Executor was employed to dispatch the events. Please refer to ExecutionHandler for more information.

  • Method Details

    • handleUpstream

      void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception
      Handles the specified upstream event.
      Parameters:
      ctx - the context object for this handler
      e - the upstream event to process or intercept
      Throws:
      Exception