Application or Repository Start fails - Bad Cell format: bad type byte: 2
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
The application fails to start. The following appears in the atlassian-fisheye-YYYY-MM-DD.log and/or in the fisheye.out:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
com.cenqua.fisheye.rep.DbException: java.io.IOException: Bad Cell format: bad type byte: 2
at com.cenqua.obfuscate.idbkwvwfz._j.j(InfinityDB_1.0.53:466)
at com.cenqua.obfuscate.idbkwvwfz._j.k(InfinityDB_1.0.53:677)
at com.cenqua.obfuscate.idbkwvwfz._j.l(InfinityDB_1.0.53:762)
at com.cenqua.obfuscate.idbkwvwfz._j.d(InfinityDB_1.0.53:435)
at com.cenqua.obfuscate.idbkwvwfz._j.g(InfinityDB_1.0.53:219)
at com.cenqua.obfuscate.idbkwvwfz._j.run(InfinityDB_1.0.53:191)
at java.lang.Thread.run(Thread.java:595)
cl.fileOff=78264561
java.lang.RuntimeException: bad bits
at com.cenqua.obfuscate.idbkwvwfz._j.a(InfinityDB_1.0.53:1081)
at com.cenqua.obfuscate.idbkwvwfz._j.g(InfinityDB_1.0.53:218)
at com.cenqua.obfuscate.idbkwvwfz._j.run(InfinityDB_1.0.53:191)
at java.lang.Thread.run(Thread.java:595)
Cause
Some possibilities exist:
An Incompatible JVM (e.g. OpenJDK) is being referenced.
or
A repository index/cache has become corrupt.
or
An internal database has become corrupt (data0.bin).
Resolution
Based in order of the possible causes above:
Double check that the application references (via JAVA_HOME) a compatible JVM as identified on our Supported platforms page.
or
Removing the index/cache will cause the repository index to be recreated and depending on the size of the repository this process can be lengthy.
Replacing the index/cache with a backup will retard the repository index state to that of the backup and require that the index catch up to the present time. This is preferred to removing the index/cache completely.
Either remove the repository index/cache or replace it with a backup copy:
1) Identify the problematic repository.
2) Stop the application.
3) Remove the <FISHEYE_INST>/var/cache/<reponame> directory where <reponame> is the name of your repository.
4) Start the application.
or
Removing this internal database will cause you to lose defined user groups, group memberships, user watches, and existing notifications.
Replacing this internal database will overwrite any changes made since the backup was created.
Either remove the repository index/cache or replace it with a backup copy:
1) Stop the application.
3) Remove the file: <FISHEYE_INST>/var/data/data0.bin
4) Start the application.
Was this helpful?