qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Interupting SubscriptionManager::run()
Date Wed, 08 Jul 2009 14:45:08 GMT
Alan Conway wrote:
> Gordon Sim wrote:
>> RickW wrote:
>>> Follow up to the thread:
>>>
>>> We now use QPID two ways. (1) Message-driven programs willing to 
>>> relinquish
>>> control permanently to QPID call SubscriptionManager::run(). (2) 
>>> Programs
>>> that are not totally message-driven (those needing non-message events 
>>> like
>>> timers or operator input) use LocalQueues. Their main loop checks for 
>>> other
>>> events and then check the LocalQueues for messages.
>>>
>>> We have been unable to make the non-message-driven programs 
>>> efficient. The
>>> main loop burns 100% CPU unless we add sleeps, which means we are doing
>>> nothing when there could be messages to process.
>>>
> 
> Are you using a 0 timeout on LocalQueue::get? If you use a non-0 timeout 
> then qpid shouldn't consume CPU while waiting for a message on a 
> LocalQueue.
> 
>>> We really need something like a SubscriptionManager::runTimed(interval)
>>> call. It would process messages  (or block if none is available) for the
>>> specified interval and then return. Is there some way to do this?
>>
> 
> A loop with LocalQueue::get and a timeout should give you a similar result.

Thats fine if you only have one subscription. If not you have to either 
spin checking separate queues or block on one for a time (which may 
reduce the responsiveness to message delivery on another queue).

Allowing the same LocalQueue to be used for multiple subscriptions would 
be an alternative solution to the problem I believe.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message