1 2 Previous Next 19 Replies Latest reply on Mar 11, 2008 10:29 AM by timfox Go to original post
      • 15. Re: messages stuck in queues
        martin.wickus

        Two developers tried independently to reproduce this problem in our development environment, but no success. We've thusfar only seen it in our production and (thereafter) testing environments. The setups (firewall restrictions, machine architecture, etc) in those environment are very different from our "run everything on a windows box" development environment. I cannot rule out environmental/configuration issues our side, thus I'm not confident to claim this is a bug in JBM.

        I am going to upgrade to JBoss EAP 4.3 standard and deploy for testing.

        Tim, I think you could close the associated Jira as unable to reproduce. I'll let you know how it goes with JBoss EAP 4.3.

        Regards,
        Wickus

        • 16. Re: messages stuck in queues
          timfox

          Wickus:

          I have inspected the code and I believe I can see potential for a race condition, more here http://jira.jboss.org/jira/browse/JBMESSAGING-1245

          • 17. Re: messages stuck in queues
            timfox

            Looking at http://jira.jboss.org/jira/browse/JBMESSAGING-1245, I believe I can see a potential race condition which might give the behaviour observed.

            • 18. Re: messages stuck in queues
              martin.wickus

              Hi Tim

              Glad to hear (that we tracked it down that is). Keep us posted how the testing goes.

              Regards,
              Wickus

              • 19. Re: messages stuck in queues
                timfox

                Due to the non deterministic nature of thread scheduling this is hard to replicate since it requires, the call to changeRate to come in at that specific point, AFAICT this will only happen after the consumer is first created, so the condition is far more likely to occur if you are creating and closing consumers frequently.

                However I can easily get the condition to occur by inserting an artifical Thread.sleep(10) here:

                
                if (sendCount == num)
                 {
                
                *** here
                 try
                 {
                 Thread.sleep(10);
                 }
                 catch (Exception e)
                 {
                
                 }
                ** end here
                
                
                 clientAccepting = false;
                
                 firstTime = false;
                 }
                


                Adding proper synchronization around changeRate solves the problem,

                1 2 Previous Next