Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of gsim@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <524943D0.9070302@redhat.com>
Date: Mon, 30 Sep 2013 10:26:40 +0100
From: Gordon Sim <gsim@redhat.com>
Organization: Red Hat UK Ltd, Registered in England and Wales under Company
 Registration No. 3798903, Directors: Michael Cunningham (USA), Matt Parsons
 (USA), Charlie Peters (USA), Paul Hickey (Ireland)
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: C++ Version 0.20: Rescuing a failed connection
References: <1380280126585-7598658.post@n2.nabble.com>
In-Reply-To: <1380280126585-7598658.post@n2.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org