On Mon, Apr 2, 2018 at 10:35 PM, Rajesh Malla <mallara...@gmail.com> 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 ( http://activemq.apache.org/activemq-inactivitymonitor.html), 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 ( http://activemq.2283324.n4.nabble.com/Network-Connector-not-re-establishing-td4736881.html) 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 failure. > 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 http://activemq.apache.org/discovery-transport-reference.html. Are you using that? Tim
