1 of 1 people found this helpful
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?)
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?
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!
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.