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