<font face="trebuchet ms,sans-serif">Hi, I'm trying to achieve some degree of reliability in publishing of messages in order to guarantee that a message published by some peer gets to the broker. I am using two strategies here:</font><div>
<ul><li><font face="'trebuchet ms', sans-serif">wrap access to the channel for publishing so that publishes done by the application are first enqueued in a in-memory queue and then published to the broker only when it is known to be reachable. I am using the .NET client ConnectionShutdown events to figure out whether the broker is reachable, and rescheduling connection in case of failure. I have one thread emptying the in-memory queue which runs when the connection is established and pauses when it is not available</font></li>
<li><font face="'trebuchet ms', sans-serif">use publisher confirms and keeping track of the messages published but not acked or nacked by the broker</font></li></ul><div><font face="'trebuchet ms', sans-serif">A couple of questions:</font></div>
</div><div><ul><li><font face="'trebuchet ms', sans-serif">Is this a sensible approach? I have looked into how Shovel and (briefly) Federation handle publisher confirms when enabled but I didn't spot anything being done with unconfirmed messages except for removing them as soon as an ack from the broker arrives</font></li>
<li><font face="'trebuchet ms', sans-serif">What should I be doing with unconfirmed messages which have remained unconfirmed for some time? The broker is supposed to guarantee that either an ack or nack is sent, but what if the peer for any reason doesn't receive them for one or more messages? The unconfirmed deliveries will stay in the local collection/set/[wherever it makes sense to keep them in memory] and you would have to handle them first or then</font></li>
</ul><div><font face="'trebuchet ms', sans-serif">Thanks</font></div></div>