So here is the scenario. I have two processes trying to connect to a non-durable queue (implicitly exclusive). The first to connect successfully binds its flow to the queue, the second process fails, because only one client is allowed to bind, and just loops trying again.
I then pull the network connection on the first process (pause a b2b ncat pair to which the first process is actually connected). After around 6 seconds the first processes gets a session callback saying it is down due some TCP keep alive issue. And another event callback on the flow saying it is unbound due to session down. This is all well and good.
But the message broker seems to have a different opinion, it has no such 6 second timeout and thinks the queue is still bound to the first client, thus preventing the second client from binding its flow. I have to reconnect the network for the first process (unpause the ncat pair) and kill the first process. At that point I guess the message broker clearly gets the TCP broken pipe and only then decides that the queue is unbound from the first client and allows the second client to bind its flow.
Why this asymmetry in opinion as to whether the first client has the flow bound after the 6 second network disconnection? I'm sure there is some technical reason but from an application programming view this seems quite confusing. I'm told the flow is unbound, but actually, on the broker it is not.
P.S. I am using the C API, if that make a difference.
I think the issue you are coming into stems from the usage of a non-durable queue. Non-durable queues only support a single consumer and remain on the broker while that client is connected, plus an additional 60 seconds for unexpected disconnects.
If you want to have guaranteed delivery with Primary/Secondary consumers you probably want to use a durable exclusive queue.