2 Replies Latest reply on Feb 1, 2011 10:17 AM by Andy Taylor

    How can I close multi-threaded consumers pending on receive() calls?

    bence magyar Newbie


      I am developing a native C++ program that communicates with the JMS API through JNI.  We are using HornetQ 2.1.2 Final as our messaging vendor. The purpose of the C++ program is to consume messages from one or more topics, but I'm having trouble properly closing down connections.  To keep the discussion simple, I'll briefly describe the structure of the program:


      The main() routine creates a posix thread for each JMS topic that we want to listen on.  Each thread executes the following logic:

      (Note: this is pseudo-code)


      thread start



           consumer = new TopicConsumer();

           message  = consumer->receive();

            // do work: process the message



      // broke out of while loop, so close connection


      delete consumer;

      thread end


      Each thread should pend indefinitely for messages on their respective topic.  I don't want to call receive() with a timeout and waste cpu time looping around if no messages exist or to periodically check the "shouldCancel" flag. 


      After each thread has been kicked off, the main() routine also registers on a topic; listening for a "shutdown" message that we've defined. When the shutdown message comes in, the main() routine sets the global "shouldCancel" variable to true.  The purpose of this boolean is to alert the threads that they should break out of their "while" loops and shutdown.


      My problem:

      If I have a thread pending on a receive() call, and no messages happen to come in on that particular topic, the thread will block indefinitely and will never be aware of the "shouldCancel" state.  Is there a way for my main() routine to  "release" or "interrupt" all threads sitting on the receive() call? 


      Everything else in the program works fine, but my shutdown logic really needs to be cleaned up.  I can't imagine I'm the first person to ask about this, and I've intentionally kept my question generic because something tells me that a completely different design pattern might be a better solution here.  I'm sure you folks have seen this before.  Perhaps there are some good articles, or examples on multi-threaded subscribers that someone could point me to?