4 Replies Latest reply on Aug 31, 2011 12:42 PM by zenzei2k

    Re: Paging and Persistence disabled

    zenzei2k

      Clebert,

       

      Today I manage to run the scripts when paging starts to happen, and I'm attaching some files to see if you would be so kind to help me understand if this is a problem or not, I will be very grateful.

       

      Remember that I have persistence disabled and hornetq session configured with the pre acknowledge mode

       

      connection.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE);
      

       

      So in the past I suppose paging should not be triggered.

       

      After running both commands as

       

      C:\jboss-4.2.3.GA\server\default>java -cp ./lib/hornetq-core.jar;./lib/netty.jar org.hornetq.core.persistence.impl.journal.PrintData data\hornetq\paging data\hornetq\journal > printData.txt

      C:\jboss-4.2.3.GA\server\default>java -cp ./lib/hornetq-core.jar;./lib/netty.jar org.hornetq.core.paging.PrintPages data\hornetq\paging data\hornetq\journal > printPages.txt

       

      I got

      a) four .hq files inside data/hornetq/journal dir (attachment included journal.zip)

       

      b) two .bindings files inside data/hornetq/paging dir (attachment included paging.zip)

       

      c) Warning messages

      28/08/2011 23:34:44 org.hornetq.core.logging.impl.JULLogDelegate warn

      WARNING: Directory data\hornetq\paging\hornetq-bindings-1.bindings didn't have an identification file address.txt

      28/08/2011 23:34:44 org.hornetq.core.logging.impl.JULLogDelegate warn

      WARNING: Directory data\hornetq\paging\hornetq-bindings-2.bindings didn't have an identification file address.txt

       

      I'm also including both scripts output as attachment (printData.txt and printPages.txt zipped)

       

      Before running both scripts I saw there was one folder named 37dc4386-d1e6-11e0-b166-001dd9350b54 with a lot of files that I suppose where pages. Does the directory name represent an address, a queue on the address, or something else?

       

      Thanks in advance!

        • 1. Re: Paging and Persistence disabled
          clebert.suconic

          Your print-data is empty: you probably used a wrong directory:

           

           

          However, as I see on your print-pages:

           

          Queues = 18223,18244,18239,18726,18305,18229,18254,18218,18295,18279,18538,18274,18234,18300,18666,18284,18316,18488,18269,18259,18442,18791,18213,18289,18373,18249,18602,18359,18264

           

           

           

          You have several queues for each message. It's quite possible that you are not deleting some subscription or internal queue.

          • 2. Re: Paging and Persistence disabled
            zenzei2k

            The list of queues you post

            18223,18244,18239,18726,18305,18229,18254,18218,18295,18279,18538,18274,18234,18300,18666,18284,18316,18488,18269,18259,18442,18791,18213,18289,18373,18249,18602,18359,18264

             

            Represent the queues that do not receive the message? I have fifty queues bounded to the topic. I must say I'm forcing the situation of paging starting sending a lot of messages to a lot of queues, maybe is because of that. Do this problem will be resolved setting a TTL to the messages i'm sending?

             

            About the print-data, I don't have any bindings folder (data/hornetq/bindings), maybe is because my subscriptions aren't durable?

            • 3. Re: Paging and Persistence disabled
              clebert.suconic

              do you think you could write a quick test?

               

               

              It really seems you're not acking these messages on all the queues.

               

               

              If you are using transactioned messages... you still require some memory being used on paging.. it's not like inifite up to the disk on that case.

              • 4. Re: Paging and Persistence disabled
                zenzei2k

                Yes it's really strange. I don't have transacted messages nor queues durable.

                 

                Here is the creation of server connection

                 

                ConnectionFactory cf = (ConnectionFactory) jndiTemplate.lookup("java:/JmsXA");
                Destination topic = (Destination) jndiTemplate.lookup("topic/bingo90ManualEventTopic");
                Connection connection = cf.createConnection();
                Session session = connection.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE);
                MessageProducer producer = session.createProducer(topic);
                producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
                producer.setDisableMessageID(true);
                producer.setDisableMessageTimestamp(true);
                connection.start();
                

                 

                And here the client

                ConnectionFactory cf = (ConnectionFactory) jndiTemplate.lookup("ConnectionFactory");
                Destination destination = (Destination) jndiTemplate.lookup("topic/bingo90ManualEventTopic");
                Connection connection = cf.createConnection();
                connection.setExceptionListener(this);
                Session session = connection.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE);
                MessageConsumer consumer = session.createConsumer(destination);
                connection.start();
                

                 

                By the way I'm not making any acknowledge at the client (consciously at least), I don't know if there is any ack by default, because I thought that if I configured hornetq with the with pre_ack mode would not be necessary. Do you thins is anything wrong with this configuration or my code?

                 

                About the test I would try, but remember I'm using jboss behind. Do you think with a simple ear and testcase will suffice?

                 

                Thanks in advance and sorry for making it so large! If you want we could continue by mail or irc.