| commit | 2e53763b8442d3fba87103d7a16caf2dd9570050 | |
| author | (no author) <(no author)@41a61cd8-c433-0410-bb1c-e256eeef9e11> | |
| Thu, 13 Dec 2007 19:46:50 +0000 (13 19:46 +0000) | ||
| committer | (no author) <(no author)@41a61cd8-c433-0410-bb1c-e256eeef9e11> | |
| Thu, 13 Dec 2007 19:46:50 +0000 (13 19:46 +0000) | ||
| tree | c6e391b51b59254e25a8003e0383d277afe00f61 | treesnapshot (tar.gz zip) |
| parent | fe2862efe5b9c7fffeb940a3e8ad74576ce2d72e | commitdiff |
r1395@opsdev009 (orig r74184): jwang | 2007-12-13 11:46:27 -0800
Fix to TThriftTransport corruption detection
Summary: O_APPEND means that even if the file pointer is in the middle of the file, the next write will go to the end of the file. So when initializing the TThriftTransport to be written to, we need to truncate the file after the last good event. I'm pretty sure this was what was causing queuemap log corruption when the multiplexer is restarted.
The corruption doesn't necessarily go away at the next chunk boundary because of the offset being recalculated. I think it's good to have the offset recalculated, but then we shouldn't use the old chunk boundary data there, but rather use the newly calculated offset to determine the padding (could be an entire chunk, but that's okay -- way better than corruption)
Reviewed By: mcslee
Test Plan: Wrote to a ThriftFile using local scribe instance. Printed it. Then cat'd garbage to it from the command line. Then wrote to it again. Then printed it again. Seems to work fine, whereas with old scribe binary the later entries were corrupted.
Revert: OK
DiffCamp Revision: 4683
git-svn-id: http://svn.facebook.com/svnroot/thrift/trunk@716 41a61cd8-c433-0410-bb1c-e256eeef9e11
Fix to TThriftTransport corruption detection
Summary: O_APPEND means that even if the file pointer is in the middle of the file, the next write will go to the end of the file. So when initializing the TThriftTransport to be written to, we need to truncate the file after the last good event. I'm pretty sure this was what was causing queuemap log corruption when the multiplexer is restarted.
The corruption doesn't necessarily go away at the next chunk boundary because of the offset being recalculated. I think it's good to have the offset recalculated, but then we shouldn't use the old chunk boundary data there, but rather use the newly calculated offset to determine the padding (could be an entire chunk, but that's okay -- way better than corruption)
Reviewed By: mcslee
Test Plan: Wrote to a ThriftFile using local scribe instance. Printed it. Then cat'd garbage to it from the command line. Then wrote to it again. Then printed it again. Seems to work fine, whereas with old scribe binary the later entries were corrupted.
Revert: OK
DiffCamp Revision: 4683
git-svn-id: http://svn.facebook.com/svnroot/thrift/trunk@716 41a61cd8-c433-0410-bb1c-e256eeef9e11
| lib/cpp/src/transport/TFileTransport.cpp | diffblobblamehistory |