In an environment where the Proton C++ client is presented with a link failure without an accompanying connection failure, there does not seem to be any obvious means of restoring the link without inducing a possible memory leak. Consider the following scenario:

A client is connected to a qpid-dispatch router with a liniRoute to another router or broker, something like:

proton-cpp-client<->qpid-dispatch-1<->qpid-dispatch-2<->amq-broker

One of the upstream resources (qpid-dispatch-2 or broker) is restarted, resulting in a link failure, while the client remains connected to qpid-dispatch-1. Restoring connectivity upstream does not automatically restore the link and the client (a sender in this case) continues to report sending messages, but the messages never reach the sink (broker). Closing the sender on the client and opening a new sender seems to work (sending resumes and I can see messages reaching the broker), but this introduces a memory leak, as closing the old sender does not seem to clean up the resources (valgrind reports this as a possible leak, because the sender is still referenced by the connection). Naming the sender confirms this; if we try to close the sender and recreate it with the same name, creation fails, reporting that the link already exists.

Is there some example / method for cleaning up existing senders / receivers on a connection? Or is there another recommended approach / example for handling a link failure without a conection failure, as described above?