You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by NeilOwens <ne...@raymarine.com> on 2013/10/07 09:27:34 UTC
Re: C++ Version 0.20: Rescuing a failed connection
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
Re: C++ Version 0.20: Rescuing a failed connection
Posted by Gordon Sim <gs...@redhat.com>.
On 10/07/2013 09:38 AM, NeilOwens wrote:
> Yes, I apply a 1 second heartbeat to the connection. We're currently seeing
> a 4 second connection timeout (this is elapsed time within connection.open()
> when the destination IP address doesn't exist). We don't really want to
> have to post the connect to a different thread, so we're looking at other
> options before we do that.
Hmm, I wonder why that is... I see the timeout firing after two seconds
as expected, e.g.
./src/tests/qpid-send --connection-options '{heartbeat:1}' --address abc
--broker <bad ip> --log-enable trace+
Gives:
> 2013-10-07 10:35:41 [Client] debug Created connection 192.56.0.111 with {heartbeat:1}
> 2013-10-07 10:35:41 [Client] debug Starting connection, urls=[192.56.0.111]
> 2013-10-07 10:35:41 [Client] info Trying to connect to 192.56.0.111...
> 2013-10-07 10:35:41 [Client] debug Created IO thread: 0
> 2013-10-07 10:35:41 [Network] debug TCPConnector created for 0-10
> 2013-10-07 10:35:41 [Client] info Set TCP_NODELAY
> 2013-10-07 10:35:41 [System] info Connecting: 192.56.0.111:5672
> 2013-10-07 10:35:43 [Client] debug Traffic timeout
> 2013-10-07 10:35:43 [Network] warning Connect failed: Connection timedout
> 2013-10-07 10:35:43 [Client] warning Connection closed
> 2013-10-07 10:35:43 [System] debug Exception constructed: Connection closed
> 2013-10-07 10:35:44 [Client] info Failed to connect to 192.56.0.111: Connection closed
> qpid-send: Failed to connect (reconnect disabled)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Version 0.20: Rescuing a failed connection
Posted by NeilOwens <ne...@raymarine.com>.
Yes, I apply a 1 second heartbeat to the connection. We're currently seeing
a 4 second connection timeout (this is elapsed time within connection.open()
when the destination IP address doesn't exist). We don't really want to
have to post the connect to a different thread, so we're looking at other
options before we do that.
--
View this message in context: http://qpid.2158936.n2.nabble.com/C-Version-0-20-Rescuing-a-failed-connection-tp7598658p7599102.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
Re: C++ Version 0.20: Rescuing a failed connection
Posted by Gordon Sim <gs...@redhat.com>.
On 10/07/2013 08:27 AM, NeilOwens wrote:
> 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?
Have you tried setting a heartbeat? That should at least bound the
connect time as it will give up if it doesn't connect within two
heartbeat intervals. (That may of course not help, but just in case...)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org