diff --git a/docs/user-manual/en/configuring-transports.md b/docs/user-manual/en/configuring-transports.md
index 5f32d77dad..37e779d358 100644
--- a/docs/user-manual/en/configuring-transports.md
+++ b/docs/user-manual/en/configuring-transports.md
@@ -144,7 +144,6 @@ Out of the box, Apache ActiveMQ Artemis currently uses
 network library.
 
 Our Netty transport can be configured in several different ways; to use
-old (blocking) Java IO, or NIO (non-blocking), also to use
 straightforward TCP sockets, SSL, or to tunnel over HTTP or HTTPS..
 
 We believe this caters for the vast majority of transport requirements.
diff --git a/docs/user-manual/en/perf-tuning.md b/docs/user-manual/en/perf-tuning.md
index 653d0bead6..39f999394c 100644
--- a/docs/user-manual/en/perf-tuning.md
+++ b/docs/user-manual/en/perf-tuning.md
@@ -132,16 +132,6 @@ tuning:
     consumer-window-size. This effectively disables consumer flow
     control.
 
--   Socket NIO vs Socket Old IO. By default Apache ActiveMQ Artemis uses old (blocking)
-    on the server and the client side (see the chapter on configuring
-    transports for more information [Configuring the Transport](configuring-transports.md). NIO is much more scalable but
-    can give you some latency hit compared to old blocking IO. If you
-    need to be able to service many thousands of connections on the
-    server, then you should make sure you're using NIO on the server.
-    However, if don't expect many thousands of connections on the server
-    you can keep the server acceptors using old IO, and might get a
-    small performance advantage.
-
 -   Use the core API not JMS. Using the JMS API you will have slightly
     lower performance than using the core API, since all JMS operations
     need to be translated into core operations before the server can
diff --git a/docs/user-manual/en/thread-pooling.md b/docs/user-manual/en/thread-pooling.md
index 2d3b8d1297..1a982037ac 100644
--- a/docs/user-manual/en/thread-pooling.md
+++ b/docs/user-manual/en/thread-pooling.md
@@ -13,27 +13,7 @@ a scheduled thread pool for scheduled use. A Java scheduled thread pool
 cannot be configured to use a standard thread pool, otherwise we could
 use a single thread pool for both scheduled and non scheduled activity.
 
-A separate thread pool is also used to service connections. Apache ActiveMQ Artemis can
-use "old" (blocking) IO or "new" (non-blocking) IO also called NIO. Both
-of these options use a separate thread pool, but each of them behaves
-uniquely.
-
-Since old IO requires a thread per connection its thread pool is
-unbounded. The thread pool is created via `
-            java.util.concurrent.Executors.newCachedThreadPool(ThreadFactory)`.
-As the JavaDoc for this method states: “Creates a thread pool that
-creates new threads as needed, but will reuse previously constructed
-threads when they are available, and uses the provided ThreadFactory to
-create new threads when needed.” Threads from this pool which are idle
-for more than 60 seconds will time out and be removed. If old IO
-connections were serviced from the standard pool the pool would easily
-get exhausted if too many connections were made, resulting in the server
-"hanging" since it has no remaining threads to do anything else.
-However, even an unbounded thread pool can run into trouble if it
-becomes too large. If you require the server to handle many concurrent
-connections you should use NIO, not old IO.
-
-When using new IO (NIO), Apache ActiveMQ Artemis will, by default, cap its thread pool
+Apache ActiveMQ Artemis will, by default, cap its thread pool
 at three times the number of cores (or hyper-threads) as reported by `
             Runtime.getRuntime().availableProcessors()` for processing
 incoming packets. To override this value, you can set the number of