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 Tue, 14 Apr 2009 21:53:47 GMT
On Tue, 2009-04-14 at 13:41 -0700, RickW wrote:
> Why don't you just have the subscription manager running in its own
> thread?  I think that's the way it was designed to run.  Depending on
> what you do in your listener, you might need to use some locks.
> I don't think that will work for me. QPID is a replacement back-end for an existing messaging
API. Not all users of the existing API can tolerate listeners called on a different thread.
> Or you could use LocalQueues which allow you to call get and they will
> take care of the synchronization.
> This will work, but I think it means I have to do my own message routing. (Read from
the LocalQueues, figure out who wanted the message and call their listener(s).) This still
may be my best option.
> Can several queues feed the same LocalQueue?

No unfortunately. This would be a good improvement.

> Would my approach have worked? Or does stop() have to be called from listener thread?

Yes it would work, stop can be called from any thread. It's a bit clunky
though. What would the ideal API for your task look like? A "doWork()"
function that does a bounded amount of work rather than blocking like
run()? A file descriptor that could be polled for qpid activity? 

There's some work going on to define a more user-friendly API, I'd like
to address our threading  model as part of it.

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

View raw message