Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Date: Mon, 7 Oct 2013 00:27:34 -0700 (PDT)
From: NeilOwens <neil.owens@raymarine.com>
To: users@qpid.apache.org
Message-ID: <1381130854843-7599096.post@n2.nabble.com>
In-Reply-To: <52495932.6060107@redhat.com>
References: <1380280126585-7598658.post@n2.nabble.com>
 <524943D0.9070302@redhat.com> <1380536648521-7598800.post@n2.nabble.com>
 <524954DD.1070409@redhat.com> <1380537971230-7598802.post@n2.nabble.com>
 <52495932.6060107@redhat.com>
Subject: Re: C++ Version 0.20: Rescuing a failed connection
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We used the debug code to resolve our issue.   Reinstantiating the
connection, session and senders seems less reliable in this scenario than
keeping everything constructed, and just reopening the connection object.  I
don't know why letting the old objects go out of scope and creating them
again didn't work.

The next thing we're addressing is the connection time.  There is a fairly
long timeout on the ::connect function.  Has anyone tried changing BSDSocket
to do the set non-blocking -> connect -> select statement loop until socket
is selected for write ->set non-blocking trick to reduce the timeout?


--
View this message in context: http://qpid.2158936.n2.nabble.com/C-Version-0-20-Rescuing-a-failed-connection-tp7598658p7599096.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org