2009-11-04 4 views
2

J'utilise EHCache 1.5.0 sur une application Web exécutée sur une instance WebLogic 9.1. De temps à autre, je rencontre l'erreur suivante en récupérant un élément du cache ou en vérifiant si un élément existe dans le cache. Quelqu'un d'autre a-t-il déjà vu ce problème? Toutes les suggestions sur la façon de résoudre ce problème seraient super.Erreur EHCache lors de la recherche par clé cache

Code qui provoque ce problème:

getMyCache().isKeyInCache(cacheKey) 

configuration ehcache:

maxElementsInMemory="10000" 
eternal="false" 
timeToIdleSeconds="120" 
timeToLiveSeconds="120" 
overflowToDisk="true" 
diskPersistent="true" 

J'utilise printemps pour obtenir une instance de CacheManager et voici ma définition de haricot:

<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"> 
     <property name="configLocation"><value>classpath:ehcache.xml</value></property> 
    </bean> 

L'erreur est la suivante:

java.lang.NullPointerException 
       at net.sf.ehcache.Cache.isElementInMemory(Cache.java:1962) 
       at net.sf.ehcache.Cache.isKeyInCache(Cache.java:2075) 
       at com.test.services.impl.ContentServicesImpl.getContentItemFromCache(ContentServicesImpl.java:260) ...... 

Il n'y a rien d'autre dans le journal indiquant la cause de l'exception NullPointerException lors de la recherche d'une clé dans le cache.

Tout pointeurs, suggestions sur la façon de résoudre ce problème seront grandement appréciés. Cela n'arrive pas systématiquement, semble se produire au hasard dans un environnement.

Répondre

0

Étant donné la trace de la pile, il semble que le thread appelant voit un cache avec un MemoryStore nul (ce qui ne devrait pas être possible). Je soupçonne que cela pourrait être un problème de visibilité de la mémoire dans le code de création de CacheManager (verrouillage double-vérifié) ou le cache lui-même. Nous avons resserré beaucoup de ces problèmes de visibilité sur le terrain pour Ehcache 1.7.1 (pas encore sorti mais dans quelques semaines).

Il est donc difficile de donner une solution définitive, mais une idée merdique serait d'ajouter une certaine initialisation de ressort garantissant au début du démarrage qu'un seul thread a construit le CacheManager. Si cela faisait disparaître le problème, cela donnerait du crédit à la théorie ci-dessus.