8 Replies Latest reply on May 24, 2011 11:09 AM by Richard Schlief

    JbossMQ Message stuck

    cool gandhi Newbie

      Hi..i am new to Jboss MQ. I have a requirement in which i start some bunch of JMS Receivers to a JMS Queue.

      I keep this receivers alive instead of closing it after finishing my read. This is because i want my receiver to process the message immediately instead of it waking up periodically as it has to be real time.

      This process works fine for some time.But i observe that the receiver gets disconnected automatically after some time.And my messages are stuck in queue having no recievers to read it. i think it is due to timeour on reciever.


      Can we have a process or setting through we can manage this requirement of keeping the receiver alive throughout.

      Any help is appreciated.Thanks in advance.

        • 1. Re: Necessary to close JMS receiver connection
          Clebert Suconic Master

          I know you can with HornetQ or JBoss Messaging. You create the receiver, set the listener and it works.


          HornetQ has reconnection in place. Maybe you're having network issues and JBoss MQ is disconnecting your clients? you would need to look at code.



          Also, since you're new to JBoss MQ, why you're not going straight to HornetQ? (or at least go with JBoss Messaging).

          • 2. Re: Necessary to close JMS receiver connection
            cool gandhi Newbie

            Thanks for replying. Ya, as you said i did the same thing. I have multiple receiver on a JMS Queue.I am using ConnectionFactory which uses UIL Invoker. i have following default setting in my uil2-service.xml.

                 <attribute name="PingPeriod">60000</attribute>
                <!-- Whether tcp/ip does not wait for buffer fills -->
                <attribute name="EnableTcpNoDelay">true</attribute>
                <!-- Used to disconnect the client on the serverside if there is no activity -->
                <!-- Ensure this is greater than the ping period -->
                <attribute name="ReadTimeout">120000</attribute>
                <!-- Used to disconnect the client on the clientside if there is no activity -->
                <!-- Ensure this is greater than the ping period -->
                <attribute name="ClientReadTimeout">120000</attribute>


            What happens is my receivers work's fine for one day and next day in morning i see following MDB position through my JMX-Console:

            SubscribersCount : 2

            QueueDepth: 30000

            InProcessMessageCount: 1

            ReceiversCount: 0


            Then i manullay restarted the receivers and it worked like a charm.


            There is no exception in log and even no out of memory issue.

            Now I am unable to understand why it is happening, due to load on JMS queue or some timeout configuration is causing the receiver to timeout.

            I am using Jboss 4.2.3 GA , so the concurrent api may also not be the problem.

            I checked this forum but have not found any answer.

            Now i can't monitor this and do this manual restart every time.

            So is there anything automatic i meant which will not timeout my receiver?

            I thought my above setting in UIL xml should have taken care of this thing.

            Also one more thing, my MDB consumer clients are also in same JVM and not on other machine.

            Also should i try JVM invoker instead of UIL? I read there is no timeout issue in there.

            • 3. Re: Necessary to close JMS receiver connection
              cool gandhi Newbie

              Any help please. I have also attach some sample code.

              • 4. Necessary to close JMS receiver connection
                cool gandhi Newbie

                Can anybody please help out.I am still stuck at this issue.

                I also tried changing the invocation layer to JVM,UIL2 etc but in vain.

                On searching i found similar issue others have faced:


                but this thread talks about clutering configuration whereas i am not using it.

                But the issue is same, message getting stuck with InProcessMessageCount =1 and not getting picked even if the receiver has processed the onmessage method for previous message processed.

                Also i have set exception listener on the receiver but there is no exception thrown.

                JMS gurus please help out.

                • 5. Necessary to close JMS receiver connection
                  cool gandhi Newbie

                  Seem to have found the fix.I replaced jbossmq.jar

                  Implementation-Version: 4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=20

                  0710221139) with

                  Implementation-Version: 4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=20

                  0807181417) and its been 2 week without any problem.

                  May some fix in new version.Hope it help others.

                  • 6. JbossMQ Message stuck
                    Richard Schlief Newbie

                    Cool Gandhi,


                    You stated above you are running 4.2.3 GA, but yet you say the solution was replace the the jbossmq.jar version 4.2.2 GA with 4.2.3 GA. So you were running 4.2.3 with a 4.2.2 jbossmq.jar? 


                    I am having the same issue and I am also running 4.2.3 GA, and the jbossmq.jar is 4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=20

                    0807181439), a little newer...and I have not found a solution (other than restarting...and that's a lousy solution).



                    • 7. JbossMQ Message stuck
                      cool gandhi Newbie


                                  Sorry i wrote wrong jboss version.

                      I am using jboss-4.2.2.GA. I have replace jbossmq.jar 4.2.2.GA with version jbossmq.jar 4.2.3.GA.

                      Now i am not getting this issue anymore.

                      Try using older jboss-4.2.2.GA and check if it replicates.

                      • 8. Re: JbossMQ Message stuck
                        Richard Schlief Newbie

                          I would rather not go backwards, but I will check about it anway.