bryancall commented on issue #9752:
URL: https://github.com/apache/trafficserver/issues/9752#issuecomment-4828019488
I am closing this as stale. The two messages ("Invalid object length for
deserialization" and "HTTPInfo::response unmarshal failed") are emitted by the
experimental, undocumented `scan` subcommand of traffic_cache_tool, in
src/traffic_cache_tool/CacheScan.cc. That command walks the raw cache spans
slot by slot, so it will routinely encounter free, stale, or partially
overwritten slots that do not deserialize as valid HTTP objects, and printing
these per-slot messages is largely the expected behavior of a raw scanner
rather than a sign of an actual cache defect. Your own report notes that
diags.log and manager.log were clear, which indicates the running cache
reported no errors. The relevant code is unchanged and still present on current
master, and there has been no further activity for roughly three years. If you
are seeing genuine cache corruption (as opposed to scan noise) on a current
release, please open a new issue with a reproduction, including the Apache
Traffic Server ver
sion, the exact traffic_cache_tool invocation, and any related entries from
diags.log, and we can take another look.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
