1 2 Previous Next 18 Replies Latest reply on Feb 25, 2009 3:02 AM by Tim Fox Go to original post
      • 15. Re: DeliveryCount & ACKs
        Clebert Suconic Master

        If we decrement the delivery counter on cancelRefs, we are back to the original issue (The first post on this thread).

        I have locally done the change, and the issue happened again as I predicted.

        Another way to fix this would be to make autoCommitAcks = false (as somewhat suggested on JBMESSAGING-1294), and make the JMSWrappers to call Session.commit() when a message is received. I tried that as a quick fix and I could fix the test, however I got a few other issues on the DupsOK.

        And I also see performance issues with this, as we would make a Commit call on *every* message received on the AUTO_ACK.

        Just to make a record about what's the current issue. The parts in bold are the executed parts when the Session is AUTO_ACK. The message is aways acknowledged after listener.onMessage was called on the AUTO_ACK case:

        
         public void onMessage(final ClientMessage message)
         {
        
         JBossMessage jbm = JBossMessage.createMessage(message, session.getCoreSession());
        
         try
         {
         jbm.doBeforeReceive();
         }
         catch (Exception e)
         {
         log.error("Failed to prepare message for receipt", e);
        
         return;
         }
        
         if (transactedOrClientAck)
         {
         try
         {
         message.acknowledge();
         }
         catch (MessagingException e)
         {
         log.error("Failed to process message", e);
         }
         }
        
         try
         {
         listener.onMessage(jbm);
         }
         catch (RuntimeException e)
         {
         //See JMS 1.1 spec, section 4.5.2
        
         log.warn("Unhandled exception thrown from onMessage", e);
        
         if (!transactedOrClientAck)
         {
         try
         {
         session.getCoreSession().rollback();
        
         session.setRecoverCalled(true);
        
         }
         catch (Exception e2)
         {
         log.error("Failed to recover session", e2);
         }
         }
         }
        
         if (!session.isRecoverCalled())
         {
         try
         {
         //We don't want to call this if the consumer was closed from inside onMessage
         if (!consumer.isClosed() && !this.transactedOrClientAck)
         {
         message.acknowledge();
         }
         }
         catch (MessagingException e)
         {
         log.error("Failed to process message", e);
         }
         }
        
         session.setRecoverCalled(false);
         }
        
        




        We need to be able to rollback the current message, so the counters are set correctly.

        • 16. Re: DeliveryCount & ACKs
          Clebert Suconic Master

          So, in Summary cancelRefs is treating the currentMessage (on the MessageListener) as any other message sent and not ACKed on the buffer.

          Previously it wouldn't touch the counter as it wasn't ACKed.

          With the current changes is decrementing the counter, as it wasn't ACKed.

          • 17. Re: DeliveryCount & ACKs
            Clebert Suconic Master

            Just to close this thread, I have implemented the rollback(boolean) as we talked today on IRC.

            • 18. Re: DeliveryCount & ACKs
              Tim Fox Master

              I've just noticed that updateDeliveryCount when persistDeliveryCountBeforeDelivery = true is not syncing in the journal. It needs to sync in this case.

              if persistDeliveryCountBeforeDelivery = false it doesn't need to sync.

              1 2 Previous Next