NIO disadvantages in ActiveMQ

I've been working on configuring an ActiveMQ broker, and one thing that confuses me is that everything I've read describes NIO being "a good choice if you need to scale" or a "something to look at if you need more speed", 开发者_如何学Cso my question is why don't they just say "always use NIO"? All I've read is advantages but presumably there are reasons not to use it (otherwise it would just be the default). What are they?

---

Complexity. It is usually more simple to code for 1 thread per connection.

Also, I think NIO may be slightly slower in the small volume case (1, 2, 3 connections). Generally you wouldn't design a system to perform well in the small volume case.. but if you know you are never going to have > 2 connections for an application... maybe NIO is overkill / actually harmful.

---

The NIO transport scales better because it is more efficient and does not spawn a thread per connection. Also, the NIO transport extends the TCP transport, so all the options for the underlying socket still apply. To my knowledge, there is no downside to using NIO because overall it should be more efficient than the TCP transport. There's no good reason that I can recall for NIO not being the default transport.

---

• By adding more threads you are increasing the complexity, and the risk of potential non-delivery of messages.
• While you increase the number of parallel messages that can be handled, you may experience a delay in transferring each individual message.
• More complexity brings less reliability, so keep an eye on bugs like this, which has been Unresolved since 2019: https://issues.apache.org/jira/browse/AMQ-7343