That is the entire log message, The only way to get the actual error is via tcpdump and packet reassembly
I can't find a getImage log messages on the namenode, they would be in the jetty error log, but I think that is set to /dev/null. On Tue, Oct 13, 2009 at 10:57 PM, Raghu Angadi <[email protected]> wrote: > > It should not be very sensitive to drift. I think timestamp is meant mostly > as an increasing number. implementation might have a bug. will check. > > Could paste a larger portion of the log? > > Raghu. > > On Tue, Oct 13, 2009 at 10:47 PM, Jason Venner <[email protected]>wrote: > >> The actual body of the error contains a statement to the effect that the >> >> Namenode has an edit log with timestamp of ..... but new checkpoint >> was created using editlog with timestamp .... >> >> This is from FSImage.validateCheckpointUpload. The drift is about the >> difft in time in the edit logs. >> >> THe unique situation in my experience here is that one of the dfs.name.dir >> directories is on an nfs mounted file system, and that particular file has a >> mode time that is often 0.5+/-0.5 seconds different. >> >> Any simple fixes? Even with the best ntp, we are going to be +/- a few >> msec and the test in validateCheckpointUpoad is exact equals comparison. >> The other thing that confuses me is why, the time stamp is differenet, the >> code from a reading, appears to always pick the same file for modtime >> comparisons. >> -- >> Pro Hadoop, a book to guide you from beginner to hadoop mastery, >> http://www.amazon.com/dp/1430219424?tag=jewlerymall >> www.prohadoopbook.com a community for Hadoop Professionals >> > > -- Pro Hadoop, a book to guide you from beginner to hadoop mastery, http://www.amazon.com/dp/1430219424?tag=jewlerymall www.prohadoopbook.com a community for Hadoop Professionals
