qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Looking for feedback on a design, based on Qpid
Date Thu, 06 Sep 2012 10:20:14 GMT
On 09/05/2012 09:41 PM, Sajith Kariyawasam wrote:
> Hi all,
> This time its more like a design/architectural query I have to make, that
> it, we are going to implement a notifier functionality in our app
> deployment.
> when an application is deployed to the central server it needs to notify a
> collection of nodes that an application is uploaded/updated.
> There can be thousands of nodes of different types based on the type of
> application they are interested about.
> Here, node is the receiver and what is the best way to implement
> receiver functionality?
>      1. Should we make each and every node continuously listening to a queue
> of his type of application ?
>      2. Should the node make a call to a queue periodically and check
> whether any messages are there?
> In 1 advantage is that, the moment application gets uploaded relevent nodes
> gets the notification, but concerns about the performance.
> If solution 1 is followed, there will be thousands of active connections to
> the broker, is that manageable ? How many number of active connections Qpid
> broker can handle at large ?

I would strongly lean towards option 1. Periodically resubscribing to 
the queue and checking whether there are any messages may result in more 
broker load (in AMQP 0-10, the connection handshake is quite involved 
for example. You also would need to make sure that the reconnect/check 
cycles of the nodes were evenly spaced (since if they all checked at the 
same time that would defeat the purpose).

Several thousand connections doesn't seem problematic to me. The number 
can affect latency and even throughput, but it doesn't sound like that 
would be an issue if the alternative is periodic polling anyway.

The c++ broker uses a fixed pool of threads. It does allocate some 
buffer space per connection, but that shouldn't rule out thousands of 

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message