[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slide-dev
Subject:    Re: jakarta  SLIDE
From:       Bruno Dorel <bd.ais40 () wanadoo ! fr>
Date:       2007-02-19 8:16:38
Message-ID: 45D95CE6.90303 () wanadoo ! fr
[Download RAW message or body]

Hi all,

Antoine Levy-Lambert a écrit:

> Hello Bruno,
>
>
>
>
> Hi,
>
> Bruno Dorel has contacted me off list concerning a problem of memory  
> leak in the class ExtendedStore (src/share/org/apache/slide/store/ 
> ExtendedStore.java).
>
> Bruno, some comments about the new version of ExtendedStore.java that  
> you mailed me :
>
> 1) we would like to avoid making incompatible API changes in public  
> methods 


This doesn't change any thing, you can compile Slide project without any 
error using removeObjectFromCache(Uri key)  because the param  "key" 
passed is allways an Uri

>
>
> 2) I do not understand why changing the signature of public void  
> removeObjectFromCache(Object key) to removeObjectFromCache(Uri key)  
> solves a problem.
> toString() should always return the toString() implementation of the  
> object passed, so if the object is an Uri it should call Uri.toString().



I make some tries today and post you an anwser ASAP (I made some changes 
in Uri class so I have to check if it is not a side effect from the Uri 
class)


>
>
> In the version of ExtendedStore.java that you mailed me, there are  
> also some changes in logging behavior which should not be required.
>
> What I noticed is that you want to change the default size of a  
> number of caches. Maybe this is what really helps you fixing the  
> memory issue ? 


No , no  it was just a quick change to see the behavoir of Uri  Garbage 
Collection now I use Domain.xml to setup those values .  

>
>
> Is there a bug report in Bugzilla for this ? I would recommend  
> opening one. 


Yes  :

31924|New|Min|2004-10-27|Slide produces a lot of garbace objects and maybe


>
>
> Best regards,
>
> Antoine
>
> On Feb 16, 2007, at 9:55 AM, Bruno DOREL wrote:
>
>>
>> M. Levy-Lambert
>>
>> Merci pour votre réponse :
>>
>> En Utilisant JProfiler nous avons pu constater que des Objets Uri  
>> n'étaient pas recyclés et restaient en pile (heap) Nous avons  trouvé 
>> une fuite mémoire dans la classe Extended store au niveau de  la 
>> méthode removeObjectFromCache(Object key ) l'objet key passé en  
>> paramètre est en fait un Uri si l'on déclare le paramètre d'appel  
>> avec le type Uri les objets sont bien recyclés
>>
>>
>>
>>    /**
>>      * Removes an object from all internal caches.
>>      *
>>      * @param key the key under which the object is stored in the  
>> caches.
>>      *
>>      * BD/EADS the key is allways a Uri
>>      * public void removeObjectFromCache(Object key ) { is a bug  
>> because java
>>      * calls Object.toString and not Uri.toString so  
>> removeObjectFromCache won't
>>      * remove anything
>>      *
>>      *
>>      */
>>     public void removeObjectFromCache(Uri key ) {
>>         if (getLogger().isEnabled(LOG_CHANNEL, Logger.DEBUG)) {
>>             getLogger().log( "Removing " + key.toString() + " from  
>> cache.",
>>               LOG_CHANNEL,
>>            Logger.DEBUG );
>>         }
>>      if ( contentStore.cacheResults() && contentCachingEnabled ) {
>>       contentCache.remove( key.toString(), "_" );
>>      }
>>      if ( nodeStore.cacheResults() ) {
>>       objectsCache.remove( key.toString() );
>>      }
>>      if ( securityStore.cacheResults() ) {
>>       permissionsCache.remove( key.toString() );
>>      }
>>      // Locks shouldn't be cached, but just in case.
>>      if ( lockStore.cacheResults() ) {
>>       locksCache.remove( key.toString() );
>>      }
>>      if ( revisionDescriptorsStore.cacheResults() ) {
>>       descriptorsCache.remove( key.toString() );
>>      }
>>      if ( revisionDescriptorStore.cacheResults() ) {
>>       descriptorCache.remove( key.toString(), "-" );
>>      }
>>     }
>>
>>
>> qu'en pensez vous ? j'ai joint le fichier extendedKeyStore tel que  
>> nous l'avons codé aujourd'hui (il prend en compte d'autres  
>> modification qui feront l'objet de mes prochains mails
>>
>> en attendant une réponse
>>
>> Cordialement
>>
>> B DOREL
>>
>>
>> <ExtendedStore.java>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
> --------------------------------------------------------------------------------------- 
>
> Orange vous informe que cet  e-mail a ete controle par l'anti-virus 
> mail. Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]