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