Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of tbain98@gmail.com designates
 209.85.216.41 as permitted sender)
MIME-Version: 1.0
Sender: tbain98@gmail.com
In-Reply-To: <1421340046000-4689955.post@n4.nabble.com>
References: <1421283663687-4689939.post@n4.nabble.com>
 <1421339272906-4689951.post@n4.nabble.com>
 <1421340046000-4689955.post@n4.nabble.com>
From: Tim Bain <tbain@alumni.duke.edu>
Date: Thu, 15 Jan 2015 11:22:40 -0700
Message-ID: 
 <CAPVVMa9Npn2rOm61d6Bgk0B+CpBUe4D5iM0xz6U5V7mLtJ2G9A@mail.gmail.com>
Subject: Re: how to safely delete a cms::MessageListener object
To: ActiveMQ Users <users@activemq.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2a2902ee05d050cb4f2a0

--001a11c2a2902ee05d050cb4f2a0
Content-Type: text/plain; charset=UTF-8

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.rice@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.
>

--001a11c2a2902ee05d050cb4f2a0--