[
https://issues.apache.org/jira/browse/IMPALA-15081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107110#comment-18107110
]
Aleksandr Efimov commented on IMPALA-15081:
-------------------------------------------
Looked into the third scope item - where the high-precision or non-canonical
timestamp tokens come from. The one from IMPALA-14099 is not a high-precision
timestamp at all.
The token is 174830243931748302879977, 24 characters. Its first 13 characters
are a valid Unix epoch millisecond value, 1748302439317, which is 2025-05-26
23:33:59.317 UTC. Its last 13 characters are another valid one, 1748302879977,
about 7.3 minutes later. Those two overlap by two characters, which is why the
token is 24 long rather than 26. Read as a single integer it is far outside any
plausible range, epoch milliseconds or otherwise.
The writer side agrees on the unit: ImpalaServer::ArchiveQuery writes the
prefix with UnixMillis(), so entries carry milliseconds and nothing else.
That answers the fifth item too. There is no microsecond or nanosecond epoch to
detect, so explicit unit handling has nothing to choose between, and guessing
units would only turn a corrupt token into a plausible-looking wrong one.
On how the two got spliced: entries cannot interleave.
SimpleLogger::AppendEntry appends under log_file_lock_, so two threads in one
impalad serialise. What is left is a partial write - entries go out buffered on
purpose, "Not std::endl, since that causes an implicit flush" - and a flush
that stopped mid-token would produce exactly this shape, the first prefix cut
after eleven characters with the next entry following it. I have not
established that this is what happened, and one token is not enough to.
I do not think it needs its own issue. The tool already degrades the way you
would want: with filters enabled the bad prefix is reported with the expected
unit, counted as an error, and the entry is skipped rather than the file
abandoned. Buffered log writes that can lose a tail are a deliberate trade, and
the damage here is one unreadable entry out of a file. If a second one shows
up, this analysis is a starting point.
So once 24422 lands, the remaining scope here is empty and this can be resolved.
> Improve impala-profile-tool timestamp filter handling
> -----------------------------------------------------
>
> Key: IMPALA-15081
> URL: https://issues.apache.org/jira/browse/IMPALA-15081
> Project: IMPALA
> Issue Type: Improvement
> Reporter: Aleksandr Efimov
> Assignee: Aleksandr Efimov
> Priority: Minor
>
> impala-profile-tool supports --min_timestamp and --max_timestamp for filtering
> profile log entries by the timestamp prefix. The current upstream profile log
> writer prefixes entries with UnixMillis(), but the tool help only describes
> the
> filter value as an "integer timestamp" and parse errors do not explain the
> expected unit.
> IMPALA-14099 also surfaced a profile-log-like entry with an oversized,
> non-canonical timestamp token. The immediate fix for IMPALA-14099
> intentionally
> keeps the existing int64 timestamp-filter behavior and only avoids rejecting
> the
> profile payload when timestamp filters are not requested.
> This follow-up tracks making timestamp handling clearer and more useful.
> Proposed scope:
> - Document that --min_timestamp and --max_timestamp expect Unix epoch
> milliseconds.
> - Improve diagnostics when timestamp filters are requested but an entry's
> timestamp token is invalid or out of range.
> - Investigate where high-precision or non-canonical timestamp tokens like the
> one from IMPALA-14099 come from.
> - Consider adding human-readable filters such as --min_time/--max_time with
> ISO-8601 UTC input.
> - If real profile logs use microsecond or nanosecond epoch timestamps,
> consider
> explicit timestamp unit handling rather than silently guessing units.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
