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:[email protected]
