qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Interupting SubscriptionManager::run()
Date Wed, 08 Jul 2009 14:12:12 GMT
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.

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

View raw message