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.
>

Reply via email to