Currently toString() methods in Log operation are defined to return
NULL on insane build and return information about the log operation
only in insane builds.
For Example : in
org.apache.derby.impl.store.raw.data.InitPageOperation
public String toString(){
if (SanityManager.DEBUG)
{
.....
return super.toString() + "Init Page. Overflow = "
..
} else
return null;
}
Problem is if any one hits a recovery error , which are typically
difficult to reproduce. Error one sees is :
ERROR XSLA7: Cannot redo operation null in the log.
I was trying to debug recently an online backup test failure DERBY-973
and noticed stack does not give information about the real operation
that is failed on. Most of the log operations are driven by abstract
class PageBasicOperation.java , which appears on stack but is not of
much help.
By looking at the code I noticed a pattern of returning NULL in
toString() methods is followed by all Log Operations. I think it was
done to reduce the foot print.
I am wondering if it is really worth save these few bytes in the log
operation toString() methods. I think printing the information in the
toString() methods might give some clues to some one debugging a
recovery failure.
My first choice is to remove the DEBUG checks in the toString()
methods , if some one feels that info is not really worth increasing
the foot print by few bytes then at least making these toString()
methods to print the Log Operation that failed may be helpful.
Any comments ?
Thanks
-suresh
