Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

I don't have personal experience running with that number of connected clients (I've only used ActiveMQ with a few dozen to a few hundred), but if it's a problem, the JVisualVM CPU sampling we talked about in that thread should make that clear pretty quickly. Tim On May 19, 2017 12:11 PM,

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

Artemis has a new architecture and is more effective on keeping managing connections. Starting from the Journal where we do everything asynchronous using a lot less threads and more performant. It's the reason why Artemis merged ActiveMQ.. and it's been quite improved at 2.1.0.. It's worth to at

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

@clebertsuconic, ActiveMQ also supports NIO and we have already configured to use it. How is this different from that supported in Artemis? -- View this message in context:

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

Tim, each client process will open just one connection. There can be hundreds of thousands of different client processes (as many as no of users using our app) connected to the broker at the same time. In another thread

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

Why don't you look at ActivMQ Artemis. It's using NIO/epoll so it won't use as much memory as you keep lots of active connections. On Fri, May 19, 2017 at 8:42 AM, Tim Bain wrote: > If you have many connections from a single client process, then yes, that's > an

Re: Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

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

Is creating thousands of connections to a single AMQ broker node and keeping them open an anti-pattern?

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