Re: [xmlblaster] CacheQueueInterceptorPlugin.peek bug?

[Michele <michele at laghi.eu>]

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