Documentation for Consume states that multiple connections are required
Reading the documentation for the Consume method in the AQMP module.
I came across this (I think in reference to the nolocal parameter):
It's advisable to use separate connections for Channel.Publish and Channel.Consume so not to have TCP pushback on publishing affect the ability to consume messages, so this parameter is here mostly for completeness.
Googling TCP pushback is it not a widely used term but where it is used it seems to be treated as common knowledge. I have not encountered the term before. This reference suggests that it relates to multiplexing data over a single TCP connection such that data accumulating for one of the multiplexes/channels prevents data being read or written to the other. This is clearly something to be avoided.
The documentation quoted suggests you should open two AMQP connections one for a reading thread and one for a writing thread (if they are different) to avoid such contention. I have not seen this being practice in common use.
It does not seems to be supported by the main rabbitmq documentation for example:
After a client connects and successfully authenticates with a RabbitMQ node, it can publish and consume messages, define topology and perform other operations that are provided in the protocol and supported both by the client library and the target RabbitMQ node.
Also with AMQP you can have multiple channels per connection. How do the separate channels avoid such contention?
This stackoverflow question suggests two channels is sufficient.
This sounds like a mistake in the documentation. Or is there a specific reason why two connections ought to be used?
The documentation is referring to TCP flow control, or back pressure. Because it affects the entire connection when applied, and is only every applied to publishers, it's advised to open separate connections for publishers and consumers.
https://www.rabbitmq.com/flow-control.html https://www.brianstorti.com/tcp-flow-control/