If you have many connections from a single client process, then yes, that's an antipattern. Connection setup/teardown is somewhat expensive (and everyone will have to do it at the same time if the broker restarts), so you should be minimizing the number if possible by using a pooling connection factory. The broker also has to do a small amount of work to send keepalive messages and check for idle connections, if you're using keepalives; that's probably not a huge drain on system resources, but there's no reason to do more of it than you have to.
If you have 100,000 separate client processes, then there's nothing you can do to improve that as long as the broker process is holding up OK. (If not, increase RAM and/or put it on a machine with beefier CPUs, as needed.) The antipattern is many connections from a single process, not having lots of long-running idle connections (though you will incur the costs I described above). Tim On May 19, 2017 3:53 AM, "Shobhana" <shobh...@quickride.in> wrote: > We use a single AMQ broker (using 5.14.1 version) node to exchange MQTT > messages between our server and apps running on mobile devices (both > Android > and iOS). > The app establishes a connection with AMQ broker using Eclipse Paho client > lib. To be able to receive messages as soon as they are published, the app > keeps this connection open all the time. Even when the app is closed, a > background service gets started (in case of Android) which establishes a > connection with the broker. > In effect, if there are 100000 users using the app, there would be 100000 > connections to AMQ broker. Is there any known issue in using AMQ broker > this > way? > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/Is-creating-thousands-of-connections-to-a- > single-AMQ-broker-node-and-keeping-them-open-an-anti-patte-tp4726391.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
