[ 
https://issues.apache.org/jira/browse/OAK-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961684#comment-13961684
 ] 

Thomas Mueller commented on OAK-1666:
-------------------------------------

I'm convinced that the inUse map is not a problem. According to my test, one 
can do around 18 million (!) inUse map operations per second. Test case:

{noformat}
package org.apache.jackrabbit.core.data;

import java.lang.ref.WeakReference;
import java.util.Collections;
import java.util.Map;
import java.util.WeakHashMap;
import java.util.concurrent.CountDownLatch;

public class InUseMapTest {

    public static void main(String... args) throws Exception {
        new InUseMapTest().test();
        new InUseMapTest().test();
        new InUseMapTest().test();
    }
    
    void test() throws Exception {
        int count = 150;
        final long repeat = 100000;
        final DataIdentifier id = new DataIdentifier("abc");
        final Map<DataIdentifier, WeakReference<DataIdentifier>> inUse =
                Collections.synchronizedMap(
                new WeakHashMap<DataIdentifier, 
WeakReference<DataIdentifier>>());
        Thread[] threads = new Thread[count];
        final CountDownLatch latch = new CountDownLatch(1);
        final Exception[] ex = new Exception[1];
        for(int i=0; i<count; i++) {
            Thread t = new Thread() {
                @Override
                public void run() {
                    try {
                        latch.await();
                        for(int i=0; i<repeat; i++) {
                            inUse.put(id, new 
WeakReference<DataIdentifier>(id));
                        }
                    } catch (Exception e) {
                        ex[0] = e;
                    }
                }
            };
            t.start();
            threads[i] = t;
        }
        long time = System.currentTimeMillis();
        latch.countDown();
        for(int i=0; i<count; i++) {
            threads[i].join();
        }
        if (ex[0] != null) {
            throw ex[0];
        }
        time = System.currentTimeMillis() - time;
        System.out.println("millis: " + time);
        System.out.println("threads: " + count);
        System.out.println("repeat: " + repeat);
        System.out.println("# ISO8601.parse calls: " + count * repeat);
        System.out.println("# ISO8601.parse calls per second: " + 
                (count * repeat) * 1000 / time);
        
    }
}
{noformat}

Output for my system: 

{noformat}
millis: 801
threads: 150
repeat: 100000
# ISO8601.parse calls: 15000000
# ISO8601.parse calls per second: 18726591
millis: 819
threads: 150
repeat: 100000
# ISO8601.parse calls: 15000000
# ISO8601.parse calls per second: 18315018
millis: 841
threads: 150
repeat: 100000
# ISO8601.parse calls: 15000000
# ISO8601.parse calls per second: 17835909
{noformat}


> FileDataStore inUse map causes contention in concurrent env
> -----------------------------------------------------------
>
>                 Key: OAK-1666
>                 URL: https://issues.apache.org/jira/browse/OAK-1666
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>            Priority: Minor
>             Fix For: 1.1
>
>
> JR2 FileDataStore#inUseMap [1] is currently a synchronized map and that at 
> times causes contention concurrent env. This map is used for supporting the 
> Blob GC logic for JR2. 
> With Oak this map content is not used. As a fix we can either
> # Set inUseMap to a Guava Cache Map which has weak keys and value
> # Set inUseMap to a no op map where all put calls are ignored
> # Modify FDS to disable use of inUseMap or make {{usesIdentifier}} protected
> #3 would be a proper fix and #2 can be used as temp workaround untill FDS 
> gets fixed
> [1] 
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-data/src/main/java/org/apache/jackrabbit/core/data/FileDataStore.java#L118



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to