mjsax commented on code in PR #21414:
URL: https://github.com/apache/kafka/pull/21414#discussion_r2785860467
##########
docs/streams/core-concepts.md:
##########
@@ -75,6 +75,8 @@ The choice between event-time and ingestion-time is actually
done through the co
Kafka Streams assigns a **timestamp** to every data record via the
`TimestampExtractor` interface. These per-record timestamps describe the
progress of a stream with regards to time and are leveraged by time-dependent
operations such as window operations. As a result, this time will only advance
when a new record arrives at the processor. We call this data-driven time the
**stream time** of the application to differentiate with the **wall-clock
time** when this application is actually executing. Concrete implementations of
the `TimestampExtractor` interface will then provide different semantics to the
stream time definition. For example retrieving or computing timestamps based on
the actual contents of data records such as an embedded timestamp field to
provide event time semantics, and returning the current wall-clock time thereby
yield processing time semantics to stream time. Developers can thus enforce
different notions of time depending on their business needs.
+Kafka Streams implement stream time at two levels. At runtime, stream time is
maintained per task based on input records for that task (called "task time").
There is no global stream time, each task tracks its own stream time
independently. `Task time` is preserved across rebalances and restarts. Some
DSL operators that use grace periods maintain their own in-memory stream time
("operator time"), which is **not** preserved across rebalances or restarts and
is re-established from the first input record after restart. This distinction
affects how grace periods are applied, as they use operator time rather than
task time.
Review Comment:
```suggestion
Kafka Streams implement stream-time at two levels. At runtime, stream-time
is maintained per task based on input records for that task (called
"task-time"). There is no global stream-time and each task tracks its own
stream-time independently. Task-time is preserved across rebalances and
restarts. Some DSL operators that use grace periods maintain their own
in-memory stream-time ("operator time"), which is **not** preserved across
rebalances or restarts and is re-established from the first input record after
restart. This distinction affects how grace periods are applied, as they use
operator time rather than task time.
```
--
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]
