RpcClient not thread safe

[karlnicholas]

• RabbitMQ version:
  <groupId>com.rabbitmq</groupId>
<artifactId>amqp-client</artifactId>
<version>5.13.1</version>

• A runnable code sample, terminal transcript or detailed set of
  instructions that can be used to reproduce the issue:
  Make two threads in com.rabbitmq.client.test.RpcTest.java
  e.g. RabbitMQRpcClient

• Operating system, version, and patch level:
  Java 11: Windows 11

• Errors reported in the JavaScript console (if any):

Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - reply consumer already set, class-id=60, method-id=20)

My use case is that I am calling RpcClient from a REST service. When two clients hit the REST endpoint "at the same time" then RpcClient gives the above exception.

[michaelklishin]

Given that most clients, including this one, explicitly do not allow sharing channels across threads, I'm not sure
how much sense it makes to try make it safe.

You are welcome to look into it or simply roll your own. This "RPC client" was developed years ago primarily as an example.

[karlnicholas]

When I was using Spring's RabbitTemplate is has convertSendAndReceive which has no problems with multithreading. Since it's probably the most common usage of RabbitMQ I would say that most clients do allow multi-threading. REST and CQRS is so common these days I would imagine this is a very typical use case. It's exactly the Query part of the pattern where this is used.

[michaelklishin]

Another issue you will run into is a shared response queue. So you probably want a separate channel per thread (avoiding creating a new one of the fly every time as much as possible) and Direct reply to.

[karlnicholas]

A shared response queue is another part I've been playing with. As per the official docs, it can be fiddly to manage.

[michaelklishin]

Then a known, "static" (not constantly re-declared) response queue per client is the only option. It makes sense, since you won't have any shared topology resources in this case. No sharing => entire classes of concurrency hazards go away.