Details
-
Type:
Task
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:0.5
-
Epic Link:
-
Sprint:Sprint 19
Description
This needs to be added to jira as a race condition bug in the SortTabFile class. If you open IGB and load this genome enough times you will eventually hit this race condition error. (see comment below for exception)
Attachments
Issue Links
- relates to
-
DB-80 IGB may fail on unsorted bed files
-
- Open
-
Activity
To observe the problem:
1) Open IGB and load the S. cerevisiae genome.
2) Click through the chromosomes and verify that there is data for every chromosome
Observe: Some chromosomes may be lacking data. If IGB is closed and reopened the same thing may happen but for different chromosomes.
This behavior seems to be random in which chromosomes display data and which don't but David seems to think this could be related to how this specific bed file interacts with the IGB sorting code.
Are you noticing warnings like this?
... hundreds of these are appears when I see the bug
WARNING: block size does not agree with block starts. Ignoring YER179W on chrV
WARNING: block size does not agree with block starts. Ignoring YJR029W on chrX
WARNING: block size does not agree with block starts. Ignoring YJR079W on chrX
WARNING: block size does not agree with block starts. Ignoring YJR094W-A on chrX
WARNING: block size does not agree with block starts. Ignoring YJR112W-A on chrX
WARNING: block size does not agree with block starts. Ignoring YJR145C on chrX
WARNING: block size does not agree with block starts. Ignoring YMR242C on chrXIII
WARNING: block size does not agree with block starts. Ignoring YMR292W on chrXIII
13:40:27.640 INFO c.a.igb.view.load.GeneralLoadUtils - Loaded S. cerevisiae ...
Yes, I actually did notice this, and I am actually not seeing the exception listed in this issue.
The exception doesn't happen every time, and the missing data doesn't happen every time. Its easily reproducible, but not completely consistent. Definitely some sort of race condition.
Since the real problem behind this issue has been captured in IGBF-547 I am closing this issue. We plan to fix this issue at some point in the near future.
java.lang.ArrayIndexOutOfBoundsException: 1
at com.affymetrix.genometry.util.SortTabFile$LineComparator.minimum(SortTabFile.java:148) ~[genometry-8.3.1.jar:na]
at com.affymetrix.genometry.util.SortTabFile$LineComparator.compare(SortTabFile.java:117) ~[genometry-8.3.1.jar:na]
at com.affymetrix.genometry.util.SortTabFile$LineComparator.compare(SortTabFile.java:96) ~[genometry-8.3.1.jar:na]
at java.util.TimSort.countRunAndMakeAscending(TimSort.java:356) ~[na:1.8.0_25]
at java.util.TimSort.sort(TimSort.java:230) ~[na:1.8.0_25]
at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_25]
at java.util.ArrayList.sort(ArrayList.java:1454) ~[na:1.8.0_25]
at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_25]
at com.affymetrix.genometry.util.SortTabFile.sort(SortTabFile.java:51) ~[genometry-8.3.1.jar:na]
at com.affymetrix.genometry.symloader.SymLoader.sortCreatedFiles(SymLoader.java:96) ~[genometry-8.3.1.jar:na]
at com.affymetrix.genometry.symloader.BED.init(BED.java:90) ~[genometry-8.3.1.jar:na]
at com.affymetrix.genometry.symloader.BED.getChromosomeList(BED.java:98) ~[genometry-8.3.1.jar:na]
at com.affymetrix.genometry.quickload.QuickLoadSymLoader.loadAndAddSymmetries(QuickLoadSymLoader.java:144) ~[genometry-8.3.1.jar:na]
at com.affymetrix.genometry.quickload.QuickLoadSymLoader.loadSymmetriesThread(QuickLoadSymLoader.java:131) ~[genometry-8.3.1.jar:na]
at com.affymetrix.genometry.quickload.QuickLoadSymLoader.loadFeatures(QuickLoadSymLoader.java:111) ~[genometry-8.3.1.