ActiveMq-Cpp soConnectTimeout not working

[bpmuser]

Hello,

I'm having an issue with timeouts when I try to connect to a non-existing server using activemq-cpp.  At the moment my program simply blocks until I kill it.  I've tried using:

failover:(tcp://127.0.0.1:61616?soConnectTimeout=1)

but the program still blocks.  Am I using it wrong?

Thanks,
Brian!

[Timothy Bish]

On Wed, 2009-11-04 at 08:50 -0800, bpmuser wrote:
> Hello,
>
> I'm having an issue with timeouts when I try to connect to a non-existing
> server.  At the moment my problem simply blocks until I kill it.  I've tried
> using:
>
> failover:(tcp://127.0.0.1:61616?soConnectTimeout=1)

The failover transport is going to keep trying to reconnect here even if
the soConnectTimeout causes the attempt to connect to fail.  Have you
tried without the failover transport in the mix to see if
soConnectTimeout is working?  

tcp://127.0.0.1:61616?soConnectTimeout=1

If you are looking for a way to have the connection fail when using the
Failover transport then you'd probably want to set the
maxReconnectAttempts value on the Failover transport as follows.

failover:(tcp://127.0.0.1:61616?soConnectTimeout=1)?maxReconnectAttempts=50

Regards
Tim.

>
> but the program still blocks.  Am I using it wrong?
>
> Thanks,
> Brian!
--
Tim Bish
http://fusesource.com
http://timbish.blogspot.com/

[bpmuser]

Timothy Bish wrote:

On Wed, 2009-11-04 at 08:50 -0800, bpmuser wrote:
The failover transport is going to keep trying to reconnect here even if
the soConnectTimeout causes the attempt to connect to fail.  Have you
tried without the failover transport in the mix to see if
soConnectTimeout is working?  

tcp://127.0.0.1:61616?soConnectTimeout=1

If you are looking for a way to have the connection fail when using the
Failover transport then you'd probably want to set the
maxReconnectAttempts value on the Failover transport as follows.

failover:(tcp://127.0.0.1:61616?soConnectTimeout=1)?maxReconnectAttempts=50

Regards
Tim.

Removing failover worked, but adding maxReconnectAttemps to the failover put me into a lock again.  

I started using failover since my program was disconnecting after a minute of inactivity.  Is there a way to check the connection status and restore lost connections without the failover? Or is there a way to stop the disconnect after a minute of inactivity?

Cheers,
Brian!

[Timothy Bish]

On Wed, 2009-11-04 at 12:00 -0800, bpmuser wrote:

>
>
> Timothy Bish wrote:
> >
> > On Wed, 2009-11-04 at 08:50 -0800, bpmuser wrote:
> > The failover transport is going to keep trying to reconnect here even if
> > the soConnectTimeout causes the attempt to connect to fail.  Have you
> > tried without the failover transport in the mix to see if
> > soConnectTimeout is working?  
> >
> > tcp://127.0.0.1:61616?soConnectTimeout=1
> >
> > If you are looking for a way to have the connection fail when using the
> > Failover transport then you'd probably want to set the
> > maxReconnectAttempts value on the Failover transport as follows.
> >
> > failover:(tcp://127.0.0.1:61616?soConnectTimeout=1)?maxReconnectAttempts=50
> >
> > Regards
> > Tim.
> >
> >
>
> Removing failover worked, but adding maxReconnectAttemps to the failover put
> me into a lock again.  

Do you have an ExceptionListener registered on the Connection object?
When the max reconnect attempts is exceeded this will get called with
the error.  Where exactly are things locking, and what is the behavior
you are trying to get?

>
> I started using failover since my program was disconnecting after a minute
> of inactivity.  Is there a way to check the connection status and restore
> lost connections without the failover? Or is there a way to stop the
> disconnect after a minute of inactivity?

Using failover is a good idea in most cases as it lets your client keep
running when you restart brokers, or have other issues.  The frequent
disconnection is probably because you are using the newer 5.3 broker
which changed some things with the inactivity monitor which causes
the .Net and C++ client to do this.  You can stop this in one of three
ways.

1. add this option to your client's current URI string;
wireFormat.MaxInactivityDuration=-1

2. Change the Openwire connector configuration in ActiveMQ's
activemq.xml to the following:

<transportConnectors>
   <transportConnector name="openwire"
uri="tcp://0.0.0.0:61616?transport.keepAliveResponseRequired=true"/>
</transportConnectors>

3. Download the latest source for AMQCPP from trunk and use that, the
problem has been addressed there and should stop the frequent
disconnects.

Regards
Tim.

>
> Cheers,
> Brian!