1
votes

To try and mitigate any hangs that may come about during problems with ActiveMQ connectivity in my application, I'm looking at adding the following parameter to my broker connection string within my application:

?transport.requesttimeout=10000

According to this resource, this looks as if it will help deal with these incidents.

However, I cannot seem to get this to work with my current failover connection string, which looks like this:

failover:(tcp://masterbroker:61616,tcp://slavebroker:61616)?keepAlive=true

Adding it in thusly:

failover:(tcp://masterbroker:61616,tcp://slavebroker:61616)?keepAlive=true&transport.requesttimeout=10000

Or, alternatively like this:

failover:(tcp://masterbroker:61616?transport.requesttimeout=10000,tcp://slavebroker:61616?transport.requesttimeout=10000)?keepAlive=true

... both seem to cause NMS exceptions or failures to connect.

This may seem a relatively trivial question, but how can I specify transport specific directives within this type of connection string?

2
Please look at stackoverflow.com/a/10893701/823040. For failover mode you need transport.startupMaxReconnectAttempts, transport.timeout or related options. Full list of options: activemq.apache.org/nms/activemq-uri-configuration.html. Transport.requesttimeout is not a valid directive for failover protocol. - sgnsajgon

2 Answers

1
votes

You should always add what version of NMS.ActiveMQ you are using when asking these questions as the behaviour between versions cam vary. Assuming you are using the latest version the I'd expect a NMSException from the first form if you tried to connect to a broker and it wasn't running after about 10 seconds since, that's what the URI is telling it to do, the second URI is invalid as the only options that are applicable to the inner URI's of the failover configuration are the one's for the type of transport being called out, in this case TCP.

It might be better to take a step back and explain what you are trying to accomplish here as I don't really know what the reason you are applying the request timeout option. In most cases I would not recommend this option.

Also the keepAlive option will have no affect here as its not being applied to the tcp transports so its just going to be ignored. Beyond that tcp socket keep alive is practically useless as it only kicks in once every two hours or so, the tcp transports will do their own hearbeating for you unless you disable the inactivity monitor so their's no need for keepAlive=true.

If you can provide some more info on what the exceptions you are seeing are or what problem you are trying to solve with the request timeout I could probably answer your question better.

-Tim www.fusesource.com

-1
votes

Instead of transport.requesttimeout=10000 use connection.RequestTimeout=10000