7 Replies Latest reply on May 30, 2007 2:55 PM by Tim Fox

    Piling thread count when it polls the queue.

    praveen Newbie

      For every 10 seconds my code calls the below method to poll for new messages, but the problem is, JBoss messaging implementation is internally creating a new thread whenever it executes the session.createConsumer(queue) statement. And thread count grows continuously as it polls, after some time it ends up with Out of Memory error.

      Is it a bug in the JBM implementation or I am not doing it correctly? Please advice.


       public String pollForNewMsg() throws Exception
       {
       InitialContext ic = new InitialContext();
       ConnectionFactory cf = (ConnectionFactory)ic.lookup("/ConnectionFactory");
       Connection _jmsConn = cf.createConnection();
       Session session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
       Queue queue = (Queue)ic.lookup(queueName);
       javax.jms.MessageConsumer consumer = session.createConsumer(queue);
       conn.start();
       TextMessage msg = (TextMessage)consumer.receive(10);
       String text = msg.getText();
      
       consumer.close();
       conn.close();
      
       return text;
       }
      



      -APK.

        • 1. Re: Piling thread count when it polls the queue.
          Tim Fox Master

          Please *always* post what version of JBM, version of AS (if any), etc etc when making reports, otherwise we can't help you.

          You just haven't given enough information.

          • 2. Re: Piling thread count when it polls the queue.
            Tim Fox Master

            Also please post a *complete* test case someone can run to verify if there is a problem.

            • 3. Re: Piling thread count when it polls the queue.
              praveen Newbie

              Tim,

              Sorry I forgot to give the JBM version, it is "jboss-messaging-1.2.0.GA" version.

              Use case is simple:

              Our application creates the messages (Emails, Web services and some application tasks which can be executed asynchronously) using the JBM 1.2.0 version JMS API.

              Other side, I wrote a Consumer Manager wrapper which polls for every 10 seconds (for example) to look for the new messages in the JMS queue, wrapper class uses the JMS API to poll for a new message. Every time it polls the wrapper class creates a javax.jms.MessageConsumer object as I shown you in the code. This is where new threads are getting created and they are not getting recycled.


              For you to reproduce the problem, call the method (which I posted) continuously and monitor the JVM for total thread counts. You would see increase in thread count.


              Hope I gave you the enough information.



              Thanks,
              APK.

              • 4. Re: Piling thread count when it polls the queue.
                Tim Fox Master

                1.2.0.GA is not the latest version.

                Can you try 1.2.0.SP2? (Current latest version)

                Better still you could wait until tomorrow when I release 1.3.0.

                • 5. Re: Piling thread count when it polls the queue.
                  praveen Newbie

                   

                  "timfox" wrote:
                  1.2.0.GA is not the latest version.

                  Can you try 1.2.0.SP2? (Current latest version)

                  Better still you could wait until tomorrow when I release 1.3.0.


                  Tim,

                  I was going through the 1.3.0 documentation and it is mentioned that 1.3.0 works better with JBoss-4.2.0.GA version. We are currently using Jboss-4.0.4.GA version, do you suggest we should upgrade to Jboss-4.2.0 before we upgrade our messaging to 1.3.0?

                  Also, should JBoss-4.2.0.GA includes the messaging framework by default or we again have to go through the JBM integration instructions?

                  -APK.

                  • 6. Re: Piling thread count when it polls the queue.
                    Tim Fox Master

                    From the next release we only recommend 4.2.0.

                    This is because previous versions of AS used different versions of jars which meant people had either to do scoped deployments or do nasty hacks liking copying over newer versions of jars into AS.

                    This caused untold headache for users and support, and lead to various compatibility issues with web services and EJB3.

                    These should be a thing of the past in the next release.

                    • 7. Re: Piling thread count when it polls the queue.
                      Tim Fox Master

                      We will probably be default in 4.2.1, but installation is trivial - only 4 or 5 manual steps.

                      I wouldn't read the 1.3.0 docs yet, I haven't updated them yet. This is what remains to be done before releasing.