activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Connection questions
Date Thu, 22 Jun 2006 12:49:08 GMT
On 6/22/06, Kuppe <> wrote:
> Hi guys,
> hopefullly a simple one for you. i am using ActiveMQ RC2 to create a broker
> and multiple pub/sub clients.
> for the clients i use failover(tcp:) transport and on the broker i use the
> default broker configuration without persistence. I create all client
> connections using the createConnection() method of the
> ActiveMqConnectionFactory which has prefetch policy defined and asynch send
> and dispatch set. No other methods are called on the connection or factory
> for configuration. Specifically i do not explicitly set a client id.
> i notice the following symptom - some clients enter into an endless
> reconnect loop whilst establishing connections to the broker (actually many
> clients, and more regularly when connecting through a proxy server). on the
> broker i notice exceptions from inactivity monitor showing no activity, but
> nothing explicit regarding the specific client.
> After scanning through your forum, i noticed a possible link to the
> maxInactivityDuration and have set it to 0 for the tcp transport on the
> broker. This SEEMS to help but it SEEMS not to help in the case when clients
> are connecting through a proxy server.
> Firstly, can you help me with resolving this issue? Is there further
> optimization to be made on the broker/client?

more on this below...

> Ok, my second question is more general. When i have a number of clients
> connected to a broker which is embedded in a VM with some other service
> which the clients communicate with over the broker, it is often necessary to
> restart the services. Obviously this will also restart the broker. Should i
> expect that the clients will reconnect cleanly including recreating all
> queues/topics?

Yes - that should work fine.  Clients resume any
connections/sessions/producers/consumers after faling over to another

> Again i have looked through your forums and it SEEMS that this should work
> and am sure i have tested this. At the same time though, when i do this in
> the case where there are many more clients connected i receive many
> exceptions in the broker with the message : Client:
> ID:test-45964-1150966470288-1:5 already connected.

I think this could be caused by the broker not noticing a client has
reconnected in time. BTW can you preproduce this on 4.0?

A workaround could be for a more aggresive inactivity timeout.

> Can you please explain the reconnect process? What can i expect and what
> should i definitely NOT expect?

See above - basically cilents drop their connection and connect again.

It could be you see errors where clients try to connect too quickly
and the broker thinks its a duplicate clientID so rejects it. Maybe we
should be more clever and when a duplicate connection comes in; we
wait and see if there is any activity on the existing duplicate before

> Finally, when i set a prefetch policy to 1000 (which is recommended in your
> documentation for high throughput on fast connections) i often receive the
> error message that the message queue is full with 300 messages and that
> other threads may block.

For non-persistent messaging, the UsageManager defines the number of
messages that can be kept in RAM in the broker (since non-persistent
messaging doesn't spool to disk).

So try increasing the amount of RAM you are prepared to use for
RAM-buffering of non-persistent messaging. Or if you wanna handle
massive queues/topics you could consider using persistent messaging to
get the spooling & massive queue handling - but then just disable
synchronous sending

to get fast performance



View raw message