qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject proton Messenger error handling/recovery
Date Wed, 03 Sep 2014 19:05:28 GMT
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

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?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message