jerryshao opened a new pull request, #13381:
URL: https://github.com/apache/gravitino/pull/13381
### What changes were proposed in this pull request?
The job executor now reports when a job actually started and finished,
instead of Gravitino inferring both times from its status poll.
- **SPI**: new `JobExecutor#getJobExecutionInfo`, returning a
`JobExecutionInfo` snapshot: status, `startedAt`, `finishedAt`.
- The timestamps are attributes of the job, not of a status. Once a job
has started, every later snapshot carries its start time, including the
terminal one. So nothing is lost when a job goes from `QUEUED` to `SUCCEEDED`
between two polls.
- Its default implementation throws `UnsupportedOperationException`, so an
executor that doesn't implement it fails loudly instead of silently reporting
no times.
- `getJobStatus` becomes a default shortcut of `getJobExecutionInfo`.
- **`LocalJobExecutor`** records each job's real start and finish times, and
keeps a `JobExecutionInfo` per job instead of a `Pair<Status, Long>`.
- **`JobManager`**:
- polls with `getJobExecutionInfo`, and uses the reported times when
present. The reported start time also replaces one recorded by an earlier poll;
- without reported times, keeps the current behavior: poll time for an
observed `STARTED`, no `startedAt` for a job never observed running;
- corrects inconsistent reported data with a warning rather than failing
the poll: a time on the wrong status is dropped, a time earlier than `queuedAt`
(clock skew) is raised to it, and a `startedAt` later than `finishedAt` is
dropped;
- updates a job when its status or timestamps change, and skips the write
when nothing changes;
- takes `queuedAt` before submitting the job, so it is never later than
the reported start time.
- **Docs**: the timestamp semantics in `manage-jobs-in-gravitino.md`, the
`getJobExecutionInfo` requirement in `custom-job-executor.md`, and the meaning
of a null `startedAt` on a finished job in `JobHandle`, `JobInfo`, OpenAPI and
the Python client.
### Why are the changes needed?
`startedAt` was only set when a status poll happened to observe the job in
`STARTED`. The poll runs every `gravitino.job.statusPullIntervalInMs` (5
minutes by default), so any job shorter than that usually finished with no
`startedAt`. `finishedAt` was the time of the poll that first saw the job
finished, so it could be up to one interval late. Durations therefore reflected
the polling schedule rather than the job, and queue time couldn't be told apart
from run time.
Fix: #13365
### Does this PR introduce _any_ user-facing change?
- `startedAt` and `finishedAt` are now the actual times for jobs run by the
local job executor, including jobs that start and finish between two polls.
- **Job executor SPI**: custom job executors must implement
`getJobExecutionInfo`. One that doesn't still compiles, but fails the status
pull of its jobs with `UnsupportedOperationException`, so their status is no
longer updated.
- No REST API or configuration change.
### How was this patch tested?
- New `TestJobExecutionInfo`: the builder, the `started`/`finished` helpers,
and the `getJobExecutionInfo` default.
- `TestJobManager`:
- reported times are used;
- a reported start time replaces the poll time;
- an update with only a timestamp change is written, and one with no
change is skipped;
- inconsistent and clock-skewed reported times are corrected;
- `queuedAt` is taken before the submission.
- `TestLocalJobExecutor`: the timestamps for succeeded, failed,
cancelled-while-queued and cancelled-while-running jobs, and the cleanup of
finished jobs.
- `TestJobManagerMultiNode`: a job that finishes before it is polled records
its actual start and finish times.
- `./gradlew :core:test :server:test -PskipITs`, `spotlessCheck`,
`:docs:build`, `:api:javadoc`, `:core:javadoc`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
