On 09/27/2013 12:08 PM, NeilOwens wrote:
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.
The ProtocolRegistry[1] simply holds function pointers to functions that
return a new object. There is nothing in the code that holds on to these
objects from with the factory function or registry.
The only factory function that is actually registered is for the 1.0
implementation. The 0-10 version is the default and handling for that is
built directly into the ProtocolRegistry. However again, a new object is
created every time and no reference or pointer to it is retained by the
registry.
Did you do some debugging to lead you to the suspicion that you are
getting the same impl object? I don't see how that could happen myself.
How are you creating the new connection object? Forgive the silly
question, but are you passing in the URL to use? If you use the default
constructor the url defaults to 127.0.0.1 which may not be what you want.
Have you tried turning up logging? E.g. export QPID_LOG_ENABLE=info+ or
even debug+?
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).
--Gordon.
[1] There are actually two different ProtocolRegistry definitions, for
two different purposes. The first is for choosing the transport for an
0-10 connection (e.g. tcp, ssl, rdma), the second is for choosing the
higher level protoco or protocl version (e.g. AMQP 1.0 v. AMQP 0-10)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
