You don't really provide any meaningful info about what exactly is challenging to manage and troubleshoot with 10,000 connections. Therefore, your idea of moving to REST in the first place could be fundamentally misguided. The trouble (whatever it was) could be tied to something other than connection management which may not be solved by offloading that work to an HTTP server.
Also, you flatly assert that Artemis wasn't built with the intention of serving very large numbers of endpoints but simply with the intention of moving messages quickly between endpoints. However, Artemis was designed with high concurrency and vertical scalability in mind so I would push back on your assertion here. There is no arbitrary limit for the number of connections which a broker can support. The functional limit will depend on your hardware and your use-case. I don't really understand your question about if the "broker connection has any dependency with acceptor." Can you clarify this? Ultimately I would recommend against using the REST interface as a way to offload connection management. It wasn't designed for this purpose so I wouldn't expect it to scale well. In other words, I would expect performance to be poor. Keep in mind that messaging connections (unlike HTTP connections) are *stateful* and that state must be tracked somewhere. You can't just switch to REST and expect that to go away. If you really need to scale up the number of AMQP connections beyond what the broker is able to support I would recommend using Qpid Dispatch Router [1] as a connection concentrator. Justin [1] https://qpid.apache.org/components/dispatch-router/index.html On Mon, Dec 14, 2020 at 1:57 AM Mohan Kumar <mku...@netsurion.com.invalid> wrote: > Hi, > > Based on the suggestion from Justin Bertram I am posting my query here. > > We are new to ActiveMQ Artemis world. > When we started in ActiveMQ Artemis Broker we choose AMQP protocol to > produce and consume data from broker. > But as per the suggestion we received from ActiveMQ Artemis consultant we > switched from AMQP to REST interface. > > Reason to switch from AMQP to REST > > * As per the suggestion > > Using AMQP, one of the problem we run into managing the connections come > and go it is hard to get lot of insight into what's going on the broker. > > So it is challenging to manage and troubleshoot. > > broker aren't built with the intension of serving very large numbers of > endpoints they built with the intension of moving messages quickly between > endpoints. > > Rest: The tooling which are available in HTTP, and for scaling and for > frontend and it is really for superior to broker itself > > > > > > * When we create 10000 connection using AMQP, It creates 10000 > connections in Artemis broker(i.e. 10000 clients : 10000 connection in > Artemis broker) > > But using rest, 10000 clients connecting to HTTP server, creates 10000 > connection at HTTP server and there is only one connection from HTTP server > to REST interface. > > So there is less load in broker(less number of connection in broker) and > connection management comes to REST layer. > > > > > Our requirement is, > sensors (client which connect to Artemis server) in concurrent way we are > using AMQP acceptor in broker We would like to know: > 1. What would be maximum concurrent connection could be handled by Artemis > broker (includes both publisher and subscriber) > 2. Does broker connection has any dependency with acceptor (STOMP, AMQP, > HTTP etc...) > > Thanks, > Mohan > >
