You could probably handle that problem in most cases by adding a flag that says whether onMessage() is currently running (increment on entry, decrement on exit) combined with a long enough sleep() call; it's a bit ham-fisted, but it should be good enough. Close the consumer (so you know that there is at most one more message), sleep for your amount of time, then check whether onMessage() is still running and sleep until it's not (and maybe a bit more for good measure to make sure that the code that calls onMessage() gets a chance to finish, too), then delete the listener object. The only risk there is if you don't sleep long enough initially and there's still a message waiting to have onMessage() called, but hopefully you can find a duration that reduces that risk to close to zero even if you can't entirely prevent the issue.
A better solution would be to have a method (isSafeToDelete()?) on the listener that will return false until the listener has been closed and the last message has been processed and the thread has exited. That sounds like a useful enhancement you could request in JIRA... On Thu, Jan 15, 2015 at 9:40 AM, Steve Rice <steve.r...@teamquest.com> wrote: > Thanks for the suggestions. I have a request-and-reply mechanism, where > the > reply arrives asynchronously to a temporary queue, and a consumer has been > set up to listen for that reply sent to the temporary queue. At some > point, > after waiting awhile to receive the reply and still not getting it, the > main > thread may decide that it has given up on receiving the reply and wants to > cleanup the objects that were set up to receive the reply. It appears I > can > set the message listener associated with the consumer to NULL (or close the > consumer), which will prevent an incoming reply from calling the > onMessage() > function associated with message listener. That stops the listening. The > case I am concerned about is when the onMessage() function has begun > executing to process a reply, but has not yet reached a statement where I > can set a flag to indicate to the main thread that it is executing. At > that > moment, the main thread does not know that there is a concurrent execution > of onMessage() and may proceed with de-allocating objects used by > onMessage(). Perhaps this window of vulnerability can be closed by using > C++11 shared pointers, but that would require modifying the CMS code. > > Steve Rice > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/how-to-safely-delete-a-cms-MessageListener-object-tp4689939p4689955.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
