...

Potential approaches to this are:

1. GridNioServer
   • Pros: no dependencies, relatively easy
     • Easy to use,
     supports SSL
     • provides Future-based API
     • No extra dependencies
     • Supports multiplexing (shared worker thread group across multiple connections)
   • Cons:
     • Possibly not future proof
     ?
     • - Ignite 3.0 may change how GridNioServer works and/or switch to Netty
2. Netty
   • Pros:
     • Easy to use, provides Future-based API
     • Supports multiplexing (shared worker thread group (EventLoopGroup) across multiple connections)
     • Proven performance
   • Cons:
     • New dependency in core module
3. Perform writes in a separate thread (use dedicated thread or ForkJoinPool.commonPool)
   • Pros: no
     • No dependencies
   • Cons: more
     • Increased resource usage,
     • More manual thread management - hard to get right and fast
4. AsynchronousSocketChannel
   • Pros:
     • Native Java API, no dependencies
   • Cons:
     • SSL is very hard, making this approach not an option. See README: https://github.com/raell2/SSLAsynchronousSocketChannel
   Netty
5. Pros:
   • Greatly reduces complexity - returns ChannelFuture, which can be easily converted to IgniteClientFuture. Manual thread management goes away.
   • We can share one EventLoopGroop across all TcpClientChannel instances within ReliableChannel and reduce resource usage when partition awareness is enabled
   • Proven performance
Cons:New dependency in core module

As a result of dev list discussions (see links below), it is decided to use GridNioServer.

Discussion Links

Dev List:

...