• Bug
  • Status: Closed
  • Resolution: Fixed
  • drb
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • September 22, 2009
  • September 22, 2009

Description

RMIBootstrapCacheLoader.doLoad contains the following snippet of code:

        Element sampleElement = null;
        List keys = cachePeer.getKeys();
        for (int i = 0; i < keys.size(); i++) {
            Serializable key = (Serializable) keys.get(i);
            sampleElement = cachePeer.getQuiet((Serializable) keys.get(0));
            if (sampleElement != null) {
                break;
            }
        }
        if (sampleElement == null) {
            LOG.debug("All cache peer elements were null. Nothing to bootstrap from. Cache was "
                    + cache.getName() + ". Cache peer was " + cachePeer);
            return;
        }

The apparent flaw in the for loop is that it only ever uses the first key in the entire list of keys. Since I understand that cachePeer.getKeys() can return keys for expired elements, and yet cachePeer.getQuiet() will return null if you give it an expired key, then if the first key in the list is for an expired element, the above code will conclude that the cache is empty, even when there may be non-expired elements in there.

I suspect the intention was for the for loop to do this instead:

        for (int i = 0; i < keys.size(); i++) {
            Serializable key = (Serializable) keys.get(i);
            sampleElement = cachePeer.getQuiet(key);
            if (sampleElement != null) {
                break;
            }
        }

i.e. it actually uses the ‘key’ local variable so that it checks every key in the list. Also, perhaps it would be better if it only asked the peer for non-expired keys (effectively using Cache.getKeysWithExpiryCheck), since it doesn’t seem to be interested in expired elements anyway and fetching the keys for them is quite possibly wasteful.

Strangely this doesn’t always cause problems for me when there are expired keys returned by getKeys… sometimes I’ll try to bootstrap again seconds later and the expired keys will have disappeared. There are also occasions where this is a problem for extended periods of time and I have to restart the peer so that all expired items are cleared out. Sourceforge Ticket ID: 1664030 - Opened By: ben_piper - 20 Feb 2007 04:42 UTC

Comments

Sourceforge Tracker 2009-09-21

Logged In: YES user_id=693320 Originator: NO

Hi

Yes, I agree. Obviously this bug only shows up from time to time, but the code is clearly intended to search through looking for the first non null value upon which to base an estimate of chunk size. Fixed as per your suggestion.

This fix is in trunk and will be in 1.3.

Regards Greg Luck Comment by: gregluck - 4 Mar 2007 10:48 UTC

Fiona OShea 2009-09-22

Re-opening so that I can properly close out these issues and have correct Resolution status in Jira