[ https://issues.apache.org/jira/browse/COMPRESS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Bodewig resolved COMPRESS-285. ------------------------------------- Resolution: Fixed updated the docs > 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: XZ, performance > Fix For: 1.9 > > > 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.3.4#6332)