Thanks Michele. I think in my case though it will be better for me to continue to use the CACHE queue with maxEntriesCache = maxEntries. Since the queues hold references (only 176b each) instead of the actual messages and most of my topics don't get anywhere close to the max size, I'll be able to use large transient queues without having to worry about memory consumption getting out of hand.
Craig -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michele Sent: Tuesday, September 16, 2008 2:03 PM To: [email protected] Subject: Re: [xmlblaster] CacheQueueInterceptorPlugin.peek bug? Hi Craig, as far as I remember this solution was a trade-off between usability and implementation complexity. A re-design of the persitent queues is currently ungoing and we will look at this issue. Since this may take a while, for the time being I guess you could use a work-around by defining the history queue to use JDBC instead of CACHE. Regards Michele Craig McIlwee wrote: > I’ve recently run into some trouble with my get() calls returning less > history entries than expected and have tracked the problem down to my > history queue sizes and the CacheQueueInterceptorPlugin.peak(int, int) > method. Maybe it was designed this way on purpose, but to me the > implementation seems to have a bug: > > > > public ArrayList peek(int numOfEntries, long numOfBytes) throws > XmlBlasterException { > > synchronized(this.peekSync) { > > return this.transientQueue.peek(numOfEntries, numOfBytes); > > } > > } > > > > In my scenario I often only need to access the most recent message on a > topic, but occasionally need to access the full history. It makes sense > to me to configure my history queue like this: > > > > queue/history/maxEntriesCache = 1 > > queue/history/maxEntries = 1000 > > > > so that I only cache what I use the most but still have a large amount > of history available when necessary. This is where the peek > implementation becomes a problem, since a get() call is forwarded to the > topic’s history queue I can never get more history than the > maxEntriesCache parameter. What is the purpose of being able to store > more entries persistently if I can only ever access the number of > transient entries? Shouldn’t the implementation look more like (pseudocode) > > > > if (numEntries == -1 || numEntries > transientQueue.getMaxNumEntries()) { > > return this.persistentQueue.peek(numOfEntries, numOfBytes()); > > } else { > > return this.transientQueue.peek(numOfEntries, numOfBytes); > > } > > > > ? > > > > Thanks, > > Craig McIlwee > > Open Roads Consulting, Inc. > > 757-546-3401 > > http://www.openroadsconsulting.com > > > > This e-mail communication (including any attachments) may contain > confidential and/or privileged material intended solely for the > individual or entity to which it is addressed. If you are not the > intended recipient, you should immediately stop reading this message and > delete it from all computers that it resides on. Any unauthorized > reading, distribution, copying or other use of this communication (or > its attachments) is strictly prohibited. If you have received this > communication in error, please notify us immediately. > > >
