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.