Hi Dejan,

> the main question is do you really need that many clients and can you
> redesign your system to use smaller number of clients and selectors
> for example?

Every Client has some data which should be backuped. So if a customer has so many clients he wishes to backup it must be supported. The backup is done over direct socket communication by a legacy application, the broker wouldn't be involved for that task, he just has to inform the client about executing a job. In general the messages handled by the broker are quite small and the performance is not so important.

Currently this is done by a kind of proprietary RMI-Broker, which works ok for this issue but our Broker has some other pitfalls so we are looking for a replacement.

> as of scaling, the best starting point to scaling the broker is this
> article
> http://activemq.apache.org/how-do-i-configure-10s-of-1000s-of-queues-in-a-single-broker-.html

During my experiments i used one queue for all clients and the IP of the client as a Selector.
is it better to use one queue for every client when having many clients?

> You may also want to consider creating a network of brokers for this > task.

Yes this sounds very interesting.
So for supporting 5000 clients its possible to use 10 Brokers each handling connections for 500 clients? If i understand this strategy/feature correctly it should be possible to support 100 of 1000s of clients?! Ok its some work to configure/administer all these brokers but if a network of brokers works reliable this is definitely something i should evaluate.



Reply via email to