This is a cross-compiled version running on an embedded ARM processor. I'm seeing odd behaviour in reacquiring a connection to a remote unit that's rebooted. I have created a MessageSender object that's managing all the qpid objects and it's created a connection, session and sender to a topic on a broker on a remote node packaged up as a BrokerSession object. However, due to the system it's running on, the remote node can be restarted, and I'm trying to get my qpid objects to recover. I've got a separate agent monitoring heartbeats to other nodes in the system, so it's been notified to deallocate the BrokerSession object.
The effect I'm seeing is that when I try to create a new connection object and open the connection I get a TransportFailure exception thrown. I attempt to back off and wait a few seconds before trying to open it again, but then get the same exception thrown again. The odd thing is that if I kill and restart the whole process, the process works perfectly. I think that even though the qpid::messaging::connection object goes out of scope, under the hood the Protocol Registry factory object is giving me the same underlying ConnectionImpl object back again, and it's giving the same error. Nothing I've tried short of that (deleting all the other qpid amalgam objects I've got floating around). Please note that my own reconnection implementation is needed because of other system knowledge the higher level objects have so they can recreate things when they know they're going to be up. My questions: a) Is there anything I can do to purge the ProtocolRegistry factory entry for that ConnectionImpl object (well, short of changing the Connection constructor). The Registry seems to be a static singleton, so only process kill will delete those objects. b) Is there anything I can call on the Connection object to get it out of its current state? The BrokerSession object closes the connection in its destructor, so is there any other cleanup I can do to stop this happening? c) Is this fixed by a later release? I can always upgrade to a later version of qpid of course, but I only want to do that if I can be sure it'll fix the problems I'm seeing, I don't want that hassle (I have a bunch of buildroot patch files I'd have to update to integrate the newer release). Thanks in advance, Neil -- View this message in context: http://qpid.2158936.n2.nabble.com/C-Version-0-20-Rescuing-a-failed-connection-tp7598658.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
