[jira] [Comment Edited] (COMPRESS-285) checking of availability of XZ compression is expensive - result should be reused

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter edited comment on COMPRESS-285 at 7/25/14 9:36 AM:
-------------------------------------------------------------------

Unfortunately it seems that the OSGi classes leak into the application's class 
loader (details below).
So it would be nice, if you provide a possibility to disable this check.

DETAILS OF MY CHECK:
I created a simple 3.0 servlet, packed it and empty web.xml (with root element 
only) into war and deployed to my glassfish 3.1.2.2 (build 5).
code:

{code:java}
@WebServlet(name="testServlet", urlPatterns={"/testServlet"})
public class TestServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse 
response) throws ServletException, IOException {
        PrintWriter out = response.getWriter();
        try {
            String clazzToLoad="org.osgi.framework.BundleEvent";
            out.println("Trying to load: " + clazzToLoad);
            Class<?> clazz = Class.forName(clazzToLoad);
            out.println("class successfully loaded");
            out.println("classloaders:");
            ClassLoader classLoader = clazz.getClassLoader();
            while (classLoader!=null){
                out.println(classLoader.getClass().getName());
                classLoader = classLoader.getParent();
            }
        } catch (ClassNotFoundException e) {
            out.println("class not available: ClassNotFoundException");
        }
        out.close();
    }
}
{code}

output:
{code}
Trying to load: org.osgi.framework.BundleEvent
class successfully loaded
classloaders:
java.net.URLClassLoader
sun.misc.Launcher$ExtClassLoader
{code}


was (Author: lsx):
Unfortunately it seems that the OSGi classes leak into the application's class 
loader (details below).
So it would be nice, if you provide a possibility to disable this check.

DETAILS OF MY CHECK:
I created a simple 3.0 servlet, packed it and empty web.xml (with root element 
only) into war and deployed to my glassfish 3.1.2.2 (build 5).
code:
@WebServlet(name="testServlet", urlPatterns={"/testServlet"})
public class TestServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse 
response) throws ServletException, IOException {
        PrintWriter out = response.getWriter();
        try {
            String clazzToLoad="org.osgi.framework.BundleEvent";
            out.println("Trying to load: " + clazzToLoad);
            Class<?> clazz = Class.forName(clazzToLoad);
            out.println("class successfully loaded");
            out.println("classloaders:");
            ClassLoader classLoader = clazz.getClassLoader();
            while (classLoader!=null){
                out.println(classLoader.getClass().getName());
                classLoader = classLoader.getParent();
            }
        } catch (ClassNotFoundException e) {
            out.println("class not available: ClassNotFoundException");
        }
        out.close();
    }
}

output:
Trying to load: org.osgi.framework.BundleEvent
class successfully loaded
classloaders:
java.net.URLClassLoader
sun.misc.Launcher$ExtClassLoader

> checking of availability of XZ compression is expensive - result should be 
> reused
> ---------------------------------------------------------------------------------
>
>                 Key: COMPRESS-285
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-285
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Compressors
>    Affects Versions: 1.5, 1.6, 1.7, 1.8
>         Environment: linux 64-bit, java 7, glassfish, solr, tika
>            Reporter: Wojciech Łozowicki
>            Priority: Minor
>              Labels: performance
>
> I use solr with apache tika for indexing documents. Tika uses 
> commons-compress to handle compressed files. Using sampler (jvisualvm) I have 
> seen that quite a lot of time (5-7%) during my tests is spent in 
> XZUtils.isXZCompressionAvailable because of unavailable XZ compression (I 
> guess for each time classloaders spend some time looking for unavailable 
> classes, then NoClassDefFoundError).
> I think the result of the first check should be stored and reused.
> Here is the stacktrace (just to show the way tika is using commons-compress):
> org.apache.commons.compress.compressors.xz.XZUtils.isXZCompressionAvailable(XZUtils.java:52)
>       at 
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:140)
>       at 
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:95)
>       at 
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:81)
>       at 
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:61)



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