commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wojciech Łozowicki (JIRA) <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-285) checking of availability of XZ compression is expensive - result should be reused
Date Wed, 23 Jul 2014 13:05:38 GMT

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

Wojciech Łozowicki commented on COMPRESS-285:
---------------------------------------------

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)

Mime
View raw message