[jira] [Commented] (COMPRESS-162) BZip2CompressorInputStream still stops after 900,000 decompressed bytes of large compressed file
[ https://issues.apache.org/jira/browse/COMPRESS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147118#comment-13147118 ] Stefan Bodewig commented on COMPRESS-162: - Thank you for checking. > BZip2CompressorInputStream still stops after 900,000 decompressed bytes of > large compressed file > > > Key: COMPRESS-162 > URL: https://issues.apache.org/jira/browse/COMPRESS-162 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: Linux (Fedora Cores 13 [2.6.34.9-69.fc13.i686.PAE] and > 15, at latest 'yum upgrade' as of 7 Nov 2011), Sun Java 1.6.0_22 >Reporter: Andrew Pavlin > Fix For: 1.4 > > > Attempting to unzip the planet-110921.osm.bz2 file downloaded directly from > planet.OpenStreetMaps.org aborts after exactly 90 bytes are uncompressed. > The uncompressed content looks like valid XML, and causes my application's > parser to blow up with XML syntax errors due to missing closing tags. Tried > using the example code to just uncompress, and got the same exact behavior. > Uncompressing the same file planet-110921.osm.bz2 (19357793489 bytes long > compressed) with the Linux bzip2 command-line utility > (bzip2-1.0.6-1.fc13.i686.rpm) succeeds and produces a valid (and enormous) > XML file that can be successfully parsed. > Tried getting a subversion snapshot of the commons-compress trunk on 7 Nov > 2011 and replacing the org.apache.commons.compress.compressors.bzip2 package > in the commons-compress-1.3.jar with compiled code from the trunk (Subversion > log reported that the fix for COMPRESS-146 (?) was in). Still the same > failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-162) BZip2CompressorInputStream still stops after 900,000 decompressed bytes of large compressed file
[ https://issues.apache.org/jira/browse/COMPRESS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147017#comment-13147017 ] Andrew Pavlin commented on COMPRESS-162: Turns out everything works just fine when I use the 2-arg constructor. Please close this issue as a duplicate of 146. > BZip2CompressorInputStream still stops after 900,000 decompressed bytes of > large compressed file > > > Key: COMPRESS-162 > URL: https://issues.apache.org/jira/browse/COMPRESS-162 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: Linux (Fedora Cores 13 [2.6.34.9-69.fc13.i686.PAE] and > 15, at latest 'yum upgrade' as of 7 Nov 2011), Sun Java 1.6.0_22 >Reporter: Andrew Pavlin > > Attempting to unzip the planet-110921.osm.bz2 file downloaded directly from > planet.OpenStreetMaps.org aborts after exactly 90 bytes are uncompressed. > The uncompressed content looks like valid XML, and causes my application's > parser to blow up with XML syntax errors due to missing closing tags. Tried > using the example code to just uncompress, and got the same exact behavior. > Uncompressing the same file planet-110921.osm.bz2 (19357793489 bytes long > compressed) with the Linux bzip2 command-line utility > (bzip2-1.0.6-1.fc13.i686.rpm) succeeds and produces a valid (and enormous) > XML file that can be successfully parsed. > Tried getting a subversion snapshot of the commons-compress trunk on 7 Nov > 2011 and replacing the org.apache.commons.compress.compressors.bzip2 package > in the commons-compress-1.3.jar with compiled code from the trunk (Subversion > log reported that the fix for COMPRESS-146 (?) was in). Still the same > failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-162) BZip2CompressorInputStream still stops after 900,000 decompressed bytes of large compressed file
[ https://issues.apache.org/jira/browse/COMPRESS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146294#comment-13146294 ] Andrew Pavlin commented on COMPRESS-162: switched to the two-arg constructor with true for the second argument, and now it isn't stopping (yet). I'll provide further feedback after it finishes the file (my app takes about 12 hours to parse the entire planet.osm file). > BZip2CompressorInputStream still stops after 900,000 decompressed bytes of > large compressed file > > > Key: COMPRESS-162 > URL: https://issues.apache.org/jira/browse/COMPRESS-162 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: Linux (Fedora Cores 13 [2.6.34.9-69.fc13.i686.PAE] and > 15, at latest 'yum upgrade' as of 7 Nov 2011), Sun Java 1.6.0_22 >Reporter: Andrew Pavlin > > Attempting to unzip the planet-110921.osm.bz2 file downloaded directly from > planet.OpenStreetMaps.org aborts after exactly 90 bytes are uncompressed. > The uncompressed content looks like valid XML, and causes my application's > parser to blow up with XML syntax errors due to missing closing tags. Tried > using the example code to just uncompress, and got the same exact behavior. > Uncompressing the same file planet-110921.osm.bz2 (19357793489 bytes long > compressed) with the Linux bzip2 command-line utility > (bzip2-1.0.6-1.fc13.i686.rpm) succeeds and produces a valid (and enormous) > XML file that can be successfully parsed. > Tried getting a subversion snapshot of the commons-compress trunk on 7 Nov > 2011 and replacing the org.apache.commons.compress.compressors.bzip2 package > in the commons-compress-1.3.jar with compiled code from the trunk (Subversion > log reported that the fix for COMPRESS-146 (?) was in). Still the same > failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-162) BZip2CompressorInputStream still stops after 900,000 decompressed bytes of large compressed file
[ https://issues.apache.org/jira/browse/COMPRESS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146178#comment-13146178 ] Stefan Bodewig commented on COMPRESS-162: - Andrew, are you using the two-arg constructor for BZip2CompressorInputStream? Concatenated files are not supported by default but only when you ask for it. > BZip2CompressorInputStream still stops after 900,000 decompressed bytes of > large compressed file > > > Key: COMPRESS-162 > URL: https://issues.apache.org/jira/browse/COMPRESS-162 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: Linux (Fedora Cores 13 [2.6.34.9-69.fc13.i686.PAE] and > 15, at latest 'yum upgrade' as of 7 Nov 2011), Sun Java 1.6.0_22 >Reporter: Andrew Pavlin > > Attempting to unzip the planet-110921.osm.bz2 file downloaded directly from > planet.OpenStreetMaps.org aborts after exactly 90 bytes are uncompressed. > The uncompressed content looks like valid XML, and causes my application's > parser to blow up with XML syntax errors due to missing closing tags. Tried > using the example code to just uncompress, and got the same exact behavior. > Uncompressing the same file planet-110921.osm.bz2 (19357793489 bytes long > compressed) with the Linux bzip2 command-line utility > (bzip2-1.0.6-1.fc13.i686.rpm) succeeds and produces a valid (and enormous) > XML file that can be successfully parsed. > Tried getting a subversion snapshot of the commons-compress trunk on 7 Nov > 2011 and replacing the org.apache.commons.compress.compressors.bzip2 package > in the commons-compress-1.3.jar with compiled code from the trunk (Subversion > log reported that the fix for COMPRESS-146 (?) was in). Still the same > failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
