activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <>
Subject Re: facility for temporary connections?
Date Mon, 29 Mar 2010 11:32:50 GMT
Hi Joe,

one queue sounds better thread-wise. As the number of clients broker can
handle, it's best to do some testing and find that figure for your

Dejan Bosanac -

Open Source Integration -
ActiveMQ in Action -
Blog -

On Mon, Mar 29, 2010 at 12:11 PM, joe <> wrote:

> 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
> >
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message