RpcClient breaks on broker restart

[CuriusAlgo]

The RpcClient resets its consumer when a shutdown signal is received src/main/java/com/rabbitmq/client/RpcClient.java. However, it does not cancel the consumer like RpcClient.close() does. That means that if the broker restarts, and a new RpcClient is instantiated (because the old client has shut down and can't be used any more), a ShutdownSignalException is raised: 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)

As a workaround, I stored the RpcClient consumer externally and cancelled it once the RpcClient _consumer was set to null. Afterwards, I could instantiate a new RpcClient without causing the ShutdownSignalException.

RabbitMQ version: 3.7.7
Java client version: 5.3.0

[michaelklishin]

@acogoluegnes do we care to address this, given that those classes are first and foremost examples?

[acogoluegnes]

@michaelklishin This doesn't seem too much involving and specific, we could address it.

[acogoluegnes]

@CuriusAlgo @michaelklishin I added a test case to reproduce the issue. It can be mitigated by disabling topology recovery (as the consumer isn't re-registered on topology recovery). Cancelling the consumer on connection failure works too, but it's kind of an ugly hack: basicCancel obviously fails because the connection is dead, but the consumer is actually removed from the topology history, so it's not recovered afterwards.

I'm not sure what to do here, maybe providing a hook somewhere in RpcClient to handle the consumer cancellation could be an acceptable solution.

[michaelklishin]

@acogoluegnes we could introduce a recovery API extension that would let the caller to remove a consumer from the recorded consumer map. Then this class would be able to use it. We already have similar hooks for queues (IIRC).

[acogoluegnes]

Follow-up issue: #383.