AbstractBootstrap#handler vs. ServerBootstrap#childHandler for ServerBootstrap?

Question

I'd like to revivify this one and Manish Maheshwari's answer, in particular. Where is documented that

The handler, which is defined in the AbstractBootstrap is used when writing Netty based clients.

and

When writing Netty based servers [use] childHandler as defined in the ServerBootstrap.

In other words, where is the difference in

val b = new ServerBootstrap()
b.group(boss, wrkr)
 .channel(classOf[NioServerSocketChannel])
 .handler(new LoggingHandler(LogLevel.INFO))
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .childHandler(new ChannelInitializer[SocketChannel]() {
   override def initChannel(ch: SocketChannel): Unit =
     ch.pipeline()
       .addLast(new LoggingHandler(LogLevel.INFO))
       .addLast(new StringDecoder())
       .addLast(new StringEncoder())
 })

and

val b = new ServerBootstrap()
b.group(boss, wrkr)
 .channel(classOf[NioServerSocketChannel])
 .childHandler(new ChannelInitializer[SocketChannel]() {
   override def initChannel(ch: SocketChannel): Unit =
     ch.pipeline()
       .addLast(new LoggingHandler(LogLevel.INFO))
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       .addLast(new StringDecoder())
       .addLast(new StringEncoder())
 })

Answer 1

handler registers a channel handler for the parent channel
childHandler registers a channel handler for child channels
The seemingly same handlers listen to events on different channels and have different behaviors.

In the case of LoggingHandler, the first one logs events happened in the parent channel, which includes port binding and accepting new connections. So it produces logs (simplified and commented) like below:

// parent channel registered
INFO - [id: 0xb94a8e7c] REGISTERED
// parent channel binds to localhost:8009
INFO - [id: 0xb94a8e7c] BIND: 0.0.0.0/0.0.0.0:8009
// parent channel active
INFO - [id: 0xb94a8e7c, L:/0:0:0:0:0:0:0:0:8009] ACTIVE
// parent channel accepts new connection, child channel with id 0xe507ce8f created
INFO - [id: 0xb94a8e7c, L:/0:0:0:0:0:0:0:0:8009] RECEIVED: [id: 0xe507ce8f, L:/0:0:0:0:0:0:0:1:8009 - R:/0:0:0:0:0:0:0:1:54398]

Suppose the child channel reads the data in the request, the logger in your second will produce something like:

// child channel registered
INFO - [id: 0x15fee362, L:/0:0:0:0:0:0:0:1:8009 - R:/0:0:0:0:0:0:0:1:55459] REGISTERED
// child channel active
INFO - [id: 0x15fee362, L:/0:0:0:0:0:0:0:1:8009 - R:/0:0:0:0:0:0:0:1:55459] ACTIVE
// child channel received 7 bytes of data, "hello\r\n"
INFO - [id: 0x15fee362, L:/0:0:0:0:0:0:0:1:8009 - R:/0:0:0:0:0:0:0:1:55459] RECEIVED: 7B
// logs the hex dump of the received data
+-------------------------------------------------+ | 0 1 2 3 4 5 6 7 8 9 a b c d e f | +--------+-------------------------------------------------+----------------+ |00000000| 68 65 6c 6c 6f 0d 0a |hello.. | +--------+-------------------------------------------------+----------------+