• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • alexsnaps
  • Reporter: tormp
  • November 10, 2009
  • 1
  • Watchers: 2
  • January 15, 2010
  • December 02, 2009

Description

net.sf.ehcache.constructs.blocking.SelfPopulatingCache always reports “null” for the offending key when an exception is thrown refreshing the cache.

The problem comes from an uninitialized stack variable, keyWithException. It should be set in the catch() block, before it is used in the log message:


    public void refresh(boolean quiet) throws CacheException {

        Exception exception = null;
===>        Object *keyWithException* = null;

        // Refetch the entries
        final Collection keys = getKeys();

        if (LOG.isLoggable(Level.FINE)) {
            LOG.fine(getName() + ": found " + keys.size() + " keys to refresh");
        }

        // perform the refresh
        for (Iterator iterator = keys.iterator(); iterator.hasNext();) {
            final Object key = iterator.next();

            try {
                Ehcache backingCache = getCache();
                final Element element = backingCache.getQuiet(key);

                if (element == null) {
                    if (LOG.isLoggable(Level.FINE)) {
                        LOG.fine(getName() + ": entry with key " + key + " has been removed - skipping it");
                    }

                    continue;
                }

                refreshElement(element, backingCache, quiet);
            } catch (final Exception e) {
                // Collect the exception and keep going.
                // Throw the exception once all the entries have been refreshed
                // If the refresh fails, keep the old element. It will simply become staler.
                LOG.log(Level.WARNING, getName() + "Could not refresh element " + key, e);
                exception = e;
            }
        }

        if (exception != null) {
 ===>           throw new CacheException(exception.getMessage() + " on refresh with key " + *keyWithException*);
        }
    }

Comments

Alexander Snaps 2009-12-02

Also added the cause to the CacheException being thrown