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? Would my approach have worked? Or does stop() have to be called from listener thread? -- View this message in context: http://n2.nabble.com/Interupting-SubscriptionManager%3A%3Arun%28%29-tp2634272p2635248.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
