db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Log operation classes toString() methods returns NULL in non-debug builds
Date Fri, 17 Feb 2006 01:41:01 GMT
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












Mime
View raw message