4 Replies Latest reply on May 24, 2012 9:52 AM by kreedtek21

    Last-value queues start paging and don't stop

    kreedtek21

      When an address is set to page, but is also defined as a last-value queue, once it starts paging it doesn't appear to stop.  This started with 2.2.x (tested with 2.1.2.Final, 2.2.2.Final, 2.2.5.Final and 2.2.14.Final).  When doing the test in 2.1.2.Final, it would delete the page files after de-paging (which I would expect).  I am trying to confirm if what I saw before is correct to expect now.  I will say that many other features related to paging that went into the 2.2.x series are really nice, especially the ability to get the message count even when paging.

       

      To activate the test, you can use the distributed examples/jms/paging and make the following edits:

       

      hornetq-configuration.xml: Add <last-value-queue>true</last-value-queue> to the address-setting of jms.queue.pagingQueue

      src/org/hornetq/jms/example/PagingExample.java; In the for loop for the pagingQueue producer, add this above the send:

      message.setStringProperty("_HQ_LVQ_NAME", "id" + i);

       

      Now if you run the test, the normal queue page files will be deleted, but the pagingQueue page files won't be.  Plus, if you run it again, new page files will be created for that queue and it continues to grow.

        • 1. Re: Last-value queues start paging and don't stop
          clebert.suconic

          It's probably a bug. I don't think we have any tests with last-value-queue and paging. (you should probably avoid using paging with last-value-queue.. it doesn't make any sense anyways.. does it?)

          1 of 1 people found this helpful
          • 2. Re: Last-value queues start paging and don't stop
            kreedtek21

            The issue we have is that we want to clear out the producer messages, so we went with paging.  I am now working with an address policy of block and experimenting with journal size configurations, per your recommendation.

             

            The reason we went the original route was because we have a system that generates many updates to records, similar to the stock prices example, and so wanted the last-value queue to only perform SQL updates from the source messages based on the last update, not each incremental change.  There can be updates to a record 15+ times in a second.  And, there can be 200 of those records in about 3 seconds.  This is not a problem in itself, except that those records have related data (as many as another 7-10 different record types) that is also changing multiple times and need to be processed in order.

             

            Also, the consumers are sometimes across a slow WAN link, so didn't want unnecessary messages being sent, so needed the last-value queue option.

             

            If the combination will not be supported, for now apparent reasons, then I will work with the blocking option and find ways to improve performance on the producer side.  Otherwise, should I file a bug?

            • 3. Re: Last-value queues start paging and don't stop
              clebert.suconic

              Last-value-queue shouldn't really build up messages up to the point it starts to page? I don't get why you would use paging?

               

              I'm just saying I don't get it!

              • 4. Re: Last-value queues start paging and don't stop
                kreedtek21

                Thank you for the clarification.  I have changed from paging to bolocking and adjusted the memory and journal settings to allow the system to perform better without getting a back-log on the producer.