On 09/30/2013 11:24 AM, NeilOwens wrote:
Thanks for your reply, Gordon.
I hadn't confirmed using instrumentation that the same ConnectionImpl is
being returned, it was just a (apparently wrong) guess looking at the code.
It's somewhat difficult to isolate this scenario in a simpler situation. I
have my code I'm calling:
m_Connection = qpid::messaging::Connection("10.0.0.5:5672");
m_Connection.setOption("heartbeat", 1);
m_Connection.open();
after 10.0.0.5 has been rebooted. I get a TransportFailure exception
("Failed to connect (reconnect disabled)") thrown from m_Connection.open(),
and continues to do so until I restart the application. Destroying all of
my amalgam objects doesn't seem to clear the fault, only restarting the
whole linux process. This made me think that some kind of bad state was
sticking around through all my objects going out of scope.
It could well be.
Another possibility that occurred to me (without knowledge of your code
of course), is that the reconnect took a different path resulting in the
open() being called on an object that wasn't initialised as expected for
some reason (e.g. a connection handle held in a map or something). From
the snippet above, that doesn't seem to be the case though.
Looking at the Connection.cpp source made me think that the ConnectionImpl
was a function of the options and protocol. However, I'm not supplying any
options, so looking at ProtocolRegistry::create it should be returning 0 and
so it should be creating a new ConnectionImpl object each time.
However, the empirical observation is that something somewhere is continuing
to maintain state that isn't backing off properly. I have an older version
which still has the startup bug if you try and start the broker without
--log-enable, so I've got that set to warning+ at the moment. I'll try
increasing the logging level, but it's a busy broker so there's a lot of
spam to pick through.
Actually I meant turn on logging on the client side. The broker logging
won't be that useful. What I really want to see is the logs from the
connection attempts.
My next guess is that there's something in the Connector object that is
failing to connect. I'm guessing the factory stuff in there will end up
getting a TCPConnector, and thence doing stuff in posix::AsynchConnector and
BSDSocket::connect. I'll add some more logging and get back to you.
Thanks again
--
View this message in context:
http://qpid.2158936.n2.nabble.com/C-Version-0-20-Rescuing-a-failed-connection-tp7598658p7598800.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
