1 2 3 4 Previous Next 59 Replies Latest reply on Jun 20, 2011 1:58 AM by jamshed.katta Go to original post
      • 30. Re: Possible Deadlock Sending to JMS Queue
        hosier.david

        Just so it's not lost in my previous, more lengthy post... I am not closing or removing any subscriber. I'm just creating one subscriber and running the test, which hangs every time.

        • 31. Possible Deadlock Sending to JMS Queue
          hosier.david

          By the way, I really appreciate the continued engagement on this.

          • 32. Possible Deadlock Sending to JMS Queue
            hosier.david

            Forgot to point out that, as Bill has described, the REST interface of HornetQ is actually doing the ack of the messages, not the push subscriber.

            • 33. Possible Deadlock Sending to JMS Queue
              clebert.suconic

              AFAIK the ACK is done when the message is consumed at the client.

               

              On your case you are creating the subscription but not consuming. It seems that messages are being pushed to the subscription but you are never consuming. As a result messages would only build on server.

               

               

              I could replicate your test here, I'm just doing a few extra tests to confirm that theory.

              • 34. Possible Deadlock Sending to JMS Queue
                clebert.suconic

                Bill Burke would be able to say this right away.

                 

                 

                I'm getting acquainted to the Rest implementation that Bill wrote now. I may take longer than Bill as he wrote the stuff, but I will get there.

                • 35. Possible Deadlock Sending to JMS Queue
                  bill.burke

                  Thanks Clebert, I'm not going to be able to take a look at this until Friday.

                  • 36. Possible Deadlock Sending to JMS Queue
                    hosier.david

                    Of course I'm "consuming", how else would I be printing the messages that my subscription is getting to the log? I am using a push subscription, which means that I've provided a URI to the HornetQ REST subscription, and the REST interface POSTs each message to that URI. I'm pretty sure Bill already stated on this thread that the REST interface acks the messages prior to POSTing them to that endpoint. I can see the log message coming from Bill's code that says he's acking the messages, but the messages don't appear to be getting acked, which is the problem at hand. If you look back in this thread, you should also see that I asked you specifically if I should be seeing certain logging coming from the core HornetQ code when an ack happens, because I see nothing, even when I have TRACE logging turned on for "org". When the messages are sent, I see tons of logging from HornetQ, so I thought it was strange that I would see nothing when messages were supposed to be getting acked.

                    • 37. Possible Deadlock Sending to JMS Queue
                      bill.burke

                      No, the REST push subscription does NOT ack *prior* to pushing message to HTTP endpoint.  This is the algorithm:

                       

                      onMessage(message)

                      {

                          1. forward message via HTTP

                          2. If sent successfully, message.acknowledge()

                          3. If not sent successfully, throw RuntimeException

                      }

                       

                      Thats it.

                      • 38. Possible Deadlock Sending to JMS Queue
                        hosier.david

                        Also, you might look at http://anonsvn.jboss.org/repos/hornetq/trunk/hornetq-rest/hornetq-rest/src/main/java/org/hornetq/rest/queue/push/PushConsumer.java, as that appears to be the code that is pushing the message to my URI. The onMessage() method has the log message I was referring to that I see when the REST interface says that it's acking the message. You can see from that code that the HornetQ REST code is the one doing the acking for a push subscription.

                        • 39. Possible Deadlock Sending to JMS Queue
                          hosier.david

                          Right, ok. I just saw that when looking at the class I just linked to. I was going to modify that class to log any exception explicitly in the case that perhaps it is getting an exception and the re-thrown exception is being eaten somewhere.

                          • 40. Possible Deadlock Sending to JMS Queue
                            hosier.david

                            I can confirm that it is indeed the PushConsumer class that sends the messages. I added some logging to that class, and I can also confirm that the code is not getting any exceptions either. But I also think I may have just found the problem. PushConsumer calls acknowledge on the ClientMessage. According to the javadoc of ClientMessage, "If the session responsible to acknowledge this message has  {@code autoCommitAcks} set to {@code true}, the transaction will automatically commit the current transaction. Otherwise, this acknwoledgement will not be committed until the client commits the session transaction." Also in PushConsumer, the session is created with

                             

                            session = factory.createSession(false, false);

                             

                            This means the session does not have auto-ack turned on. PushConsumer never calls ClientSession.commit(). Thus the messages are never acked. I am going to change the code and test again to see if I am correct.

                            • 41. Possible Deadlock Sending to JMS Queue
                              hosier.david

                              Yep, that was the problem! I know that calling session.commit() after doing the ack fixes the problem. I assume that creating the session with autCommitAcks set to true would also solve the problem. The question is, which way is better?

                              1 of 1 people found this helpful
                              • 42. Possible Deadlock Sending to JMS Queue
                                clebert.suconic

                                I got the same conclusion as you in parallel (I didn't see your last post while I was debugging)

                                 

                                 

                                The best would be to have factory.createSession (true, true, 0); (ACK Batch Size == 0)

                                 

                                That means that the ACK is sent to the server right away.

                                 

                                 

                                @Bill: Do you plan adding any support for commit calls on Rest.

                                 

                                 

                                @David: I committed this on trunk: you should be able to svn update, get the source code from trunk and build the rest module.

                                • 43. Possible Deadlock Sending to JMS Queue
                                  hosier.david

                                  I see that you changed QueueConsumer as well to use the autCommitAck. It may be premature to make that change in that location. That class looks like it services the pull subscriptions, which do allow you to manually acknowledge according to the REST API documentation (see specifically Section 5.2.2 of the REST User Manual). Of course, I could be totally wrong here. I will build and run my test again.

                                  • 44. Possible Deadlock Sending to JMS Queue
                                    clebert.suconic

                                    The only thing I changed there on QueueConsumer was the ACK-Batch-Size.

                                     

                                    ACK-Batch-Size > 0 is like DupsOK on JMS terms. The ack won't get effective until you have more than a certain number of messages acked.

                                     

                                     

                                    @Bill: Can you take a look on my changes?