owebeeone / jbzip2 Goto Github PK

A colleague and I noticed that FastQC 0.11.2 
(http://www.bioinformatics.babraham.ac.uk/projects/fastqc/) and Trimmomatic 
0.32 (http://www.usadellab.org/cms/?page=trimmomatic) had problems with many 
.bz2 files that were compressed with pbzip2. I traced this to an issue with the 
bundled jbzip2 0.9.0, though I verified that the issue is present in both 
jbzip2 0.9.1 and the current trunk (revision r43) as well.

The attached file (Clean_Miseq_S3_R1.fastq.bz2) was compressed with pbzip2 
1.1.8, using the -p1 option to avoid the chance of encountering any latent 
race-condition bug triggered by the use of multiple threads:

bzip2 1.0.6 has no problem has no problem decompressing this file:

However, the jbzip2 0.9.1 demo.Decompress exits with status 0, but results in a 
truncated file whose size appears to correspond to the default bzip2 900k block 
size:

jbzip2 0.9.1 has no problem decompressing the file when compressed with bzip2:

--
Nathan Weeks
IT Specialist
USDA-ARS Corn Insects and Crop Genetics Research Unit
Crop Genome Informatics Laboratory
Iowa State University
http://weeks.public.iastate.edu/
https://www.linkedin.com/in/nweeks

Please see the attached patch. This will help with publishing artifacts to 
Maven Central via SontaType OSSRH.
It essentially introduces a pom.xml file and implements the typical expects 
Maven directory structure e.g. src/main/java.
From top directory in trunk, it can be applied as follows

patch -p0 -i bzip2.maven.patch

You can then build the project by invoking 

$ cd jbzip2/
$ mvn install 

What steps will reproduce the problem?
We run a very complex mapped object tree, with several levels of nested objects 
in lists, where each list can contain large amounts (thousands) of objects. 
Dozer handles this without a problem, but of course - very slowly. 
Orika's overhead is negligable to non-existant (we map objects that are about 
2-4 mb of binary data usually under 1 ms). so performance wise it's very good.
anyhow - it seems that from time to time an object from a different path in the 
object tree get's mapped to the wrong list:
i.e.
myObject.myList<FirstType>.nestedList<NestedType>
would get objects from
myObject.otherList<SecondType>

the really strange thing is that nested list would contain mostly NestedType an 
one instance of SecondType

reproduction is consistent when a large enough object tree (say 2-3 levels of 
nesting, thousands of objects in the lists) and enough executions of the mapper.
out of 800 mappings of the root object i consistently get 3-4 class cast 
exceptions while iterating on those lists.

This seems to happen only after the code has been compiled into byte code - 
that's my diagnosis based on the fact that it happens very intermittently, and 
far more frequently on "run" configuration rather than on "debug".
i would say that it was a race-condition but i am running on a single thread so 
 i don't see how that would be possible. but that might be all-together 
unrelated.

What version of the product are you using? On what operating system?
we're using the latest 1.2.0 version, but this goes back as at lest 1.1.5 which 
was the first version we tried. i check every release to see if it was resolved.

Please provide any additional information below.