Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.3
-
Fix Version/s: 1.3.1
-
Labels:None
-
Patch Submitted:Yes
-
Number of attachments :
Description
The root cause of the problem is that the HashSet implementation changed between JDK 1.4 and JDK 1.6.
TransactionLogRecord.calulateCrc32() iterates over the HashSet containing uniqueNames to calculate the CRC32. In JDK 1.4, the order in which unique names are added to the HashSet does no matter: the iteration will always return them in a static order. Under JDK 1.6, the order of the elements during the iteration COULD depend on the insertion order in the HashSet:
In JDK 1.4, iterating this HashSet:
Set uniqueNames = new HashSet();
names.add("abc");
names.add("xyz");
will always return xyz then abc
In JDK 1.6, we could get abc then xyz or xyz then abc. This depends on the hash value, add order and other internal implementation details.
Since the CRC32 of (abc xyz) is NOT the same as the one of (xyz abc) it could be that during swapJournalFiles() while the TransactionLogRecord are being re-read that they are iterated in another order than the insertion one thus leading to a different CRC32.
Changing the TransactionLogRecord constructors to accept SortedSet instead of Set will fix this issue. The only caveat is that this change requires a minor change in the Journal interface:
public void log(int status, Uid gtrid, Set uniqueNames) throws IOException;
has to be changed to:
public void log(int status, Uid gtrid, SortedSet uniqueNames) throws IOException;
See: http://www.nabble.com/Corrupted-log-td19329045.html