1

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?

rvxnet
  • 457
  • 5
  • 16
  • Please look at http://stackoverflow.com/a/10893701/823040. For failover mode you need **transport.startupMaxReconnectAttempts**, **transport.timeout** or related options. Full list of options: http://activemq.apache.org/nms/activemq-uri-configuration.html. Transport.requesttimeout is not a valid directive for failover protocol. – sgnsajgon Aug 21 '14 at 20:41

2 Answers2

1

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

Tim Bish
  • 17,475
  • 4
  • 32
  • 42
  • Thanks for your response Tim. – rvxnet Apr 11 '11 at 11:55
  • I'm using the latest version of NMS - v1.5.0. Essentially the problems I am try to counter are failures in the broker causing issues within my applications (which is using synchronous sends) – rvxnet Apr 11 '11 at 12:28
  • Still not clear on what the request timeout is supposed to be fixing for you, just using the failover transport alone will detect dropped connections and reconnect to a new broker for you. You can configure reconnect attempts limits and delay values on the failover transport as well in case you don't want the client to hang on the connection.Start() method if no broker is running. – Tim Bish Apr 11 '11 at 18:41
-1

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

brasofilo
  • 25,496
  • 15
  • 91
  • 179
yavlad
  • 1
  • 1
    Can you explain why the use of `connection` helped to solve the problem? Give little explanation on why the OP need to accept your solution – olajide Oct 29 '18 at 11:49