There is nothing wrong with your current strategy. You could alternatively create a new connection on the same proactor instance. You can also reuse a connection with a new transport, for example by calling pn_proactor_release_connection() when you get the PN_TRANSPORT_CLOSED event and before calling pn_proactor_connect2() to the same address or to a failover address.
I am not aware that any of the above is a best practice in any way. Any saved teardown and re-setup operations probably occur infrequently enough in the life of the application such that you should just pick whichever best suits the design of your application. In any of the above scenarios, the application needs to track which deliveries were not settled and re-send the associated messages. The proton engine does not transfer/preserve delivery or other link state from the old link object to the new one when you recreate the link. On Fri, Aug 14, 2020 at 1:33 PM Adrian Florea <florea....@gmail.com> wrote: > > Hi, > > I have a C app using Proton-C and it is connected to an AMQP provider. > Periodically, the AMQP provider is closing the connection and I need to > reconnect (my app is supposed to run, ideally, 24/7). > > Currently, I handle this by simply catching the related transport events in > the Proactor event loop and then, when I get those errors, I free the > proactor, free the AMQP message and then go back to the initial Proactor > loop .... similar behavior as it happens when the program first starts. It > works. > > My question is: is there any best practice to handle a reconnect, less > invasive than just freeing the Proactor and starting from scratch ? > > Additionally, is there a way so I reconnect and also keep my link objects > and "reuse" / "re-attach" them after the reconnect ? > > Many thanks, > Adrian --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
