Broker.publish tries hard to establish a connection and publish its message, no matter the circumstances. The problem is that it doesn't have much information about the circumstances, so it just brute-forces broker connection.
The bigger problem that this behavior is causing is that publish requests after a Peanar shutdown force reconnection, which is completely unexpected and unwanted.
The solution lies in keeping a clear state machine about the status of the broker and its connection, and if the broker has been shutdown or have not connected, it shouldn't be the publisher's job to connect it. It can only retry on transient channel or connection failures, and even then it should not try to re-establish the connection itself. It should be the broker's job, not the publish method. The publisher should at best retry blindly with a back-off strategy. (Question: do we care about the order of messages being published? Back-off strategies could change the ordering of messages. This should be documented.)
Broker.publishtries hard to establish a connection and publish its message, no matter the circumstances. The problem is that it doesn't have much information about the circumstances, so it just brute-forces broker connection.The bigger problem that this behavior is causing is that publish requests after a Peanar shutdown force reconnection, which is completely unexpected and unwanted.
The solution lies in keeping a clear state machine about the status of the broker and its connection, and if the broker has been shutdown or have not connected, it shouldn't be the publisher's job to connect it. It can only retry on transient channel or connection failures, and even then it should not try to re-establish the connection itself. It should be the broker's job, not the publish method. The publisher should at best retry blindly with a back-off strategy. (Question: do we care about the order of messages being published? Back-off strategies could change the ordering of messages. This should be documented.)