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.
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?