Use embedded broker to reduce # of connections to remote broker?
One of our legacy applications creates over a hundred JMS connections to a topic (non persistent messages) on a remote broker (one per servlet basically). Each connection is receiving the same messages (ie same message selector). We have over a hundred instances of this application running.
I am wondering if I can simplify our setup and drastically reduce the number of connections by using an embedded activemq broker. Each app instance would run an embedded broker and the app's connections would be established to this embedded broker. I hope to configure the embedded broker as the single publisher/consumer to the remote broker; the local broker then serves it's messages to local consumers.
We also send messages from these 100+ clients, so the local broker would need to serve as a conduit for sending as well as receiving.
I hope I explained this reasonably well. Is such a setup possible? Any trade-offs I need to be aware of?
Re: Use embedded broker to reduce # of connections to remote broker?
Is this 100 connections from a single instance of the Application? If so, how about a connection pool?
Using an embedded broker might do the trick, but keep in mind that ActiveMQ is not a light solution. Embedding it has its downsides. Also, my first thought was you have 100 application instances, in which case an embedded broker would save nothing since there would be 100 embedded brokers connecting to the remote broker. Worse than that, trying to run a network of brokers with 100 brokers will prove challenging unless advisories are disabled.