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

Stefan Bodewig commented on COMPRESS-285:
-----------------------------------------

In your first solution we could use Class.forName to avoid the compile time 
dependency.  To bad it wouldn't work for you.  Can you check whether the OSGi 
classes leak into your application's class loader?

Compress is a pure library without any configuration. If you are willing to 
tell it to cache the XZ lookup we could as well manually tell Compress to not 
even try to test for XZ in CompressorStreamFactory (which probably is the root 
cause of the excessive checks you are seeing).

> 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)

Reply via email to