Hello,
I've probably missed something, but I don't know how to reliably detect
failures and reconnect.
So if I sent to an address with a freshly stood up Messenger instance
and the address can't be found things aren't too bad and I wind up with
an ECONNREFUSED that I could do something with, however if I've been
sending messages to a valid address then I kill off the consumer I see a:
[0x513380]:ERROR amqp:connection:framing-error connection aborted
[0x513380]:ERROR[-2] connection aborted
CONNECTION ERROR connection aborted (remote)
The thing is that all of these are *internally* generated messages sent
to the console via fprintf, so my *application* doesn't really know
about them (though I could be crafty and interpose my own cheeky fprintf
to intercept them). That doesn't quite sound like the desired behaviour
for a robust system?
Similarly should I actually trap an error what's the correct way to
continue, as it happens currently my app carries on silently doing
nothing useful and continuing to do so even when the peer restarts (so
there is no magic internal reconnection logic as far as I can see).
do I have to do a
messenger.stop()
messenger.start()
cycle to get things going again, I'm guessing so, but I'll like to know
what the "correct"/expected way to create Messenger code that is robust
against remote failures, as far as I can see there are no examples of
that sort of thing?
Cheers,
Frase
I've probably missed something, but I don't know how to reliably detect
failures and reconnect.
So if I sent to an address with a freshly stood up Messenger instance
and the address can't be found things aren't too bad and I wind up with
an ECONNREFUSED that I could do something with, however if I've been
sending messages to a valid address then I kill off the consumer I see a:
[0x513380]:ERROR amqp:connection:framing-error connection aborted
[0x513380]:ERROR[-2] connection aborted
CONNECTION ERROR connection aborted (remote)
The thing is that all of these are *internally* generated messages sent
to the console via fprintf, so my *application* doesn't really know
about them (though I could be crafty and interpose my own cheeky fprintf
to intercept them). That doesn't quite sound like the desired behaviour
for a robust system?
Similarly should I actually trap an error what's the correct way to
continue, as it happens currently my app carries on silently doing
nothing useful and continuing to do so even when the peer restarts (so
there is no magic internal reconnection logic as far as I can see).
do I have to do a
messenger.stop()
messenger.start()
cycle to get things going again, I'm guessing so, but I'll like to know
what the "correct"/expected way to create Messenger code that is robust
against remote failures, as far as I can see there are no examples of
that sort of thing?
Cheers,
Frase