[rfc] [icedtea-web] make PAthsAndFilles to follow seted paths IV - bubble to CacheLruWrapper

Jiri Vanek jvanek at redhat.com
Thu Apr 2 19:54:21 UTC 2015


Adapted to head.

However I have not checked removal of constructors properly... BUt Maybe I missed none. TY!

J.


On 04/01/2015 04:34 PM, Jiri Vanek wrote:
> Seems like I forgot an attachment...
>
> On 03/31/2015 03:51 PM, Jiri Vanek wrote:
>> There are/were/reappeared two issues in LRUwrapper and CacheUtils
>>
>> First the file - however crated was as value,not as pointer. So whatever happened to original, had not bubbled to lruwrapper/utils.
>> Second - the methods were using getters on field, whcch could change during the method invocation.
>>
>> This pathc should fix both of them.
>>
>> The main refactoring is
>> -    public CacheLRUWrapper(final File recentlyUsed, final File cacheDir) {
>> -        recentlyUsedPropertiesFile = new PropertiesFile(recentlyUsed);
>> +    public CacheLRUWrapper(final InfrastructureFileDescriptor recentlyUsed, final InfrastructureFileDescriptor cacheDir) {
>> +        recentlyUsedPropertiesFile = recentlyUsed;
>>
>> Now the cache lru wrapper is handling the "pointers" to sources. So any call to its "getFiles" get real value fromm PathsAndFiles
>> When any method is using its getFile it alwasy save current copy, co during runtime, it will not be affected by possible change.
>>
>> The exception is
>>
>> -    public PropertiesFile getRecentlyUsedPropertiesFile() {
>> -        return recentlyUsedPropertiesFile;
>> +    PropertiesFile getRecentlyUsedPropertiesFile() {
>> +        if (cachedPropertiesFile == null) {
>> +            //no properties file yet, create it
>> +            cachedPropertiesFile = new PropertiesFile(recentlyUsedPropertiesFile.getFile());
>> +            return cachedPropertiesFile;
>> +        }
>> +        if (recentlyUsedPropertiesFile.getFile().equals(cachedPropertiesFile.getStoreFile())){
>> +            //he underlying InfrastructureFileDescriptor is still poinitng to the same file, use current proeprties file
>> +            return cachedPropertiesFile;
>> +        } else {
>> +            //the InfrastructureFileDescriptor was set to different location, move to it
>> +            //is there something needed to close previous instance?
>> +            cachedPropertiesFile.store();
>> +            cachedPropertiesFile.unlock();
>> +            //above were just shotted here
>> +            cachedPropertiesFile = new PropertiesFile(recentlyUsedPropertiesFile.getFile());
>> +            return cachedPropertiesFile;
>> +        }
>> +
>>
>>
>> When something change value path to properties file *and* call getRecentlyUsedPropertiesFile then the file will store and unlock. (note - I dont know for sure if those two are needed, but afaik yes). So actions upo  previous Prop.File  may misbehave.
>> However .. The setter to the RECENTLY_USED_FILE and KEY_USER_CACHE_DIR is used *only* in tests (and should never be used in ITW itself)
>> Afaik - whole those will work if you run javaws (keep running) change proeprties, run second javaws. I noticed no issues. Everything was correctly cached  twice
>>
>>
>> There is one aditional refactoring in this patch - sorry for that - InfrastructureFileDescriptor moved from inner class to outer class. With one change -
>> +    //simple constructor to allow testing instances base don overrides
>> +    protected InfrastructureFileDescriptor() {
>> +        this("nope", "nope", "nope", "nope");
>> +    }
>>
>>
>> At the end, I consider this 4 pathces + lrucaches singleton + PAthsAndFiles as reallly good thing which happend to itw.
>>
>>
>> Jie - Is this enough for your "[rfc][icedtea-web] Use temporary cache in *" or is there something more to be done?
>>
>>
>> J.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: madeLRUcahceWrapperToUseInfrastructureFileDescriptorDirectly2.patch
Type: text/x-patch
Size: 33597 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20150402/9a8a12b2/madeLRUcahceWrapperToUseInfrastructureFileDescriptorDirectly2-0001.patch>


More information about the distro-pkg-dev mailing list