I built a C++ receiver based on the examples.
I notice that from time to time my process was stopping with exceptions
about the transport going away. I was able to reproduce the error by
manually restarting the broker, although it is not clear why the
connections were closing at random, the rabbitmq server log just says it
closed. Is any additional code needed in the example or the broker
config to enable heartbeats or other mechanisms to ensure long running
connections stay up?
I tried adding an implementation of on_receiver_close(proton::receiver
&r) and I found it was not being invoked at all.
Then I added an implementation of on_transport_error(proton::transport
&t) and I found it was being called. I tried various ways of bringing
up the connection again, eventually this appeared to work:
void
my_handler::on_transport_error(proton::transport &t)
{
logger.warn("transport closed unexpectedly, trying to re-establish
connection");
t.connection().container().open_receiver(mUrl);
}
Is that the only thing that is necessary to ensure reliable operation
for long-running processes? Is any additional effort needed in coding
either a sender or receiver to ensure messages are not lost or delivered
twice on reconnection?
I also noticed that some of the examples wrap the
proton::default_container::run() method in a try/catch block but apart
from logging an error, they don't make any attempt to restart the
container. Can anybody provide a more comprehensive example showing
everything that should be done to try and keep the container running?
I also assume it is good practice to wrap everything in the on_message
method in a try/catch block in case an individual message contains
unexpected content. Are there any other places where try/catch blocks
are needed with the proton API to avoid applications bailing out
unexpectedly?
Regards,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
