activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Inactivity Monitor - closing connection exactly at given timeout even keepalive true
Date Tue, 03 Apr 2018 05:18:12 GMT
On Mon, Apr 2, 2018 at 10:35 PM, Rajesh Malla <> wrote:

> 1) consumer -> broker - inactivity monitor closing connections ?
>     for this connection loss we will apply patch which you provided http
> broken. this answer we got.

OK, perfect.

>  2) while configuring n/w connector do we need to provide any inactivity
> parameters ?

As described in the documentation (, the default
values result in the inactivity monitor being active, with keep-alive
enabled. You would only need to provide parameters if you don't like the
defaults and want to have non-default behavior.

> because I have not provided due to that is it creating more tcp
> connections ?

No. The inactivity monitor does not cause multiple simultaneous
connections; at most, it would cause there to be a large number of
recently-closed sockets (in a FIN_WAIT state, for example), but that's not
what's borne out in the output you provided. The inactivity monitor is not
the cause of your multiple connections.

> from the output I am expecting is it creating more than one network
> connector [ tcp connection to other host2 ].

I agree.

In your posts on February 20 (
you indicated that you are dynamically creating your networkConnectors in
code using a UI. My starting assumption is that the large number of network
connections is due to your own code, so I'd recommend you investigate your
code to determine whether you're inadvertently creating more connections
than you should be, failing to close connections, or anything similar.

> I want broker to broker network connector should be created once and
> whenever it is disconnected by inactivity monitor then it should re-connect
> [ either failover / or spring dmlc ] so that our messages consumed by
> consumer.
> n/w connector should establish only once.

Spring DMLC is not relevant to networkConnectors; that's for client code.
The failover transport needs some specific options when used with
networkConnectors, but the examples you've given so far are for a single
underlying URI, so all you need is static. When the static transport is
used with a networkConnector, it will automatically reconnect following a

> but from output netstat, it is showing many tcp connections to other host
> that is confusing [ as I don't understand output ], so my assumption
> because
> it is creating more tcp connections with ESTABLISHED which is causing our
> application to slow down and also because of this behavior consumer is not
> able to
> establishing connection with broker [ we tried to increase ulimit also].
> [all these are my assumptions but if the netstat output is proper when we
> create n/w connector then we will think in different way after applying
> http-broken patch which you provided ].

My memory is that when you run into ulimit issues, you see those reflected
in OS logs (maybe /var/log/messages?). It's been a while since I've been
down that path, but it was possible to prove that ulimit was in fact the
root cause. You don't sound like you've actually proved that; this sounds
like guesswork on your part. Look up how to prove it, and actually prove
that that's the reason your connections are failing; otherwise, you may be
wasting your time following the wrong lead.

Also, at least one of your assumptions is flat wrong: 100 socket
connections don't by themselves cause an application to run slowly.
(Servers can have millions of open socket connections as long as the actual
workload from each is light.) So if the number of open sockets is causing
you to run slowly, it's because servicing them is consuming some scarce
computing resource (CPU, memory, etc.), and it's possible to measure each
of those things. If you're claiming that these connections are the reason
the broker is running slowly, please figure out which resource is the one
on which you're being bottlenecked. Also, since it appears that your own
code is running in the same JVM as the broker, keep in mind that the code
taking all the time might be your code rather than ActiveMQ's code.

> one more reason to ask configuration parameters about dynamic n/w connect
> is, I have seen following parameters in activemq test java files  :
> discovered.wireFormat.maxInactivityDuration

The "discovered." prefix applies to the discovery transport. See the bottom
of Are you
using that?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message