You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Michael Mikhulya (JIRA)" <ji...@apache.org> on 2015/03/05 15:45:54 UTC

[jira] [Created] (TAP5-2461) Lock contention on ZipFile.getEntry

Michael Mikhulya created TAP5-2461:
--------------------------------------

             Summary: Lock contention on ZipFile.getEntry
                 Key: TAP5-2461
                 URL: https://issues.apache.org/jira/browse/TAP5-2461
             Project: Tapestry 5
          Issue Type: Bug
          Components: tapestry-core, tapestry-ioc
            Reporter: Michael Mikhulya


Following locks are very very frequent on production environment.

{noformat}
"catalina-exec-244" #9143 daemon prio=5 os_prio=0 tid=0x00007fb350209800 nid=0x4b0a waiting for monitor entry [0x00007fb1a76b3000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.util.zip.ZipFile.getEntry(ZipFile.java:309)
        - locked <0x00000006490a34a0> (a java.util.jar.JarFile)
        at java.util.jar.JarFile.getEntry(JarFile.java:240)
        at java.util.jar.JarFile.getJarEntry(JarFile.java:223)
        at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:841)
        at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:819)
        at sun.misc.URLClassPath.findResource(URLClassPath.java:176)
        at java.net.URLClassLoader$2.run(URLClassLoader.java:557)
        at java.net.URLClassLoader$2.run(URLClassLoader.java:555)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findResource(URLClassLoader.java:554)
        at java.lang.ClassLoader.getResource(ClassLoader.java:1093)
        at org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1042)
        at org.apache.tapestry5.ioc.internal.util.ClasspathResource.resolveURL(ClasspathResource.java:79)
        at org.apache.tapestry5.ioc.internal.util.ClasspathResource.toURL(ClasspathResource.java:61)
        at org.apache.tapestry5.ioc.internal.util.AbstractResource.computeExists(AbstractResource.java:236)
        at org.apache.tapestry5.ioc.internal.util.AbstractResource.exists(AbstractResource.java:218)
        at org.apache.tapestry5.ioc.internal.util.AbstractResource.findLocalizedResource(AbstractResource.java:177)
        at org.apache.tapestry5.ioc.internal.util.AbstractResource.populateLocalizationCache(AbstractResource.java:159)
        at org.apache.tapestry5.ioc.internal.util.AbstractResource.forLocale(AbstractResource.java:136)
        at org.apache.tapestry5.internal.services.AssetSourceImpl.getLocalizedAssetFromResource(AssetSourceImpl.java:134)
        at org.apache.tapestry5.internal.services.AssetSourceImpl.getAssetInLocale(AssetSourceImpl.java:107)
        at org.apache.tapestry5.internal.services.AssetSourceImpl.getAsset(AssetSourceImpl.java:87)
        at $AssetSource_ef3168bbfb42e.getAsset(Unknown Source)
        at org.apache.tapestry5.internal.services.javascript.CoreJavaScriptStack.getJavaScriptLibraries(CoreJavaScriptStack.java:154)
{noformat}

I investegated a reason of issue.
Since tapestry-5.3.4 {{AbstractResource.forLocale}} returns the cached result.
The problem is that cache is not used in this case.
For example:
{code:title=AssetSourceImpl.java}
    private Resource findResource(Resource baseResource, String path)
    {
        assert path != null;
        int colonx = path.indexOf(':');

        if (colonx < 0)
        {
            Resource root = baseResource != null ? baseResource : prefixToRootResource.get(AssetConstants.CLASSPATH);

            return root.forFile(path);
...
{code}

Here each time new resource is created with empty cache.
So when we call {{AbstractResource.forLocale}} it is forced to call {{AbstractResource.findLocalizedResource}}.

I suggest to add simple caches (ConcurrentHashMap) in {{ClasspathResource}} and {{ContextResource}} and use this cache inside {{newResource}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)