[
https://issues.apache.org/jira/browse/KAFKA-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136446#comment-17136446
]
Piotr Smolinski commented on KAFKA-10062:
-----------------------------------------
BTW, the SystemTime class might also ensure that the time only advances by
caching the last read millis:
[https://github.com/apache/kafka/blob/2.5.0/clients/src/main/java/org/apache/kafka/common/utils/SystemTime.java]
As mentioned the system time in special cases may go back.
[https://codeburst.io/why-shouldnt-you-trust-system-clocks-72a82a41df93]
Or the restriction in MockTime should be removed, to be able to test topology
behaviour in case of NTP adjusting the clock to go back (which indeed may
happen with funny results in production):
[https://github.com/apache/kafka/blob/2.5.0/streams/test-utils/src/main/java/org/apache/kafka/streams/TopologyTestDriver.java#L1106-L1108]
On the contrary nanos are guaranteed to be monotonic (but by spec completely
unrelated to the epoch).
> Add a method to retrieve the current timestamp as known by the Streams app
> --------------------------------------------------------------------------
>
> Key: KAFKA-10062
> URL: https://issues.apache.org/jira/browse/KAFKA-10062
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Piotr Smolinski
> Assignee: William Bottrell
> Priority: Major
> Labels: needs-kip, newbie
>
> Please add to the ProcessorContext a method to retrieve current timestamp
> compatible with Punctuator#punctate(long) method.
> Proposal in ProcessorContext:
> long getTimestamp(PunctuationType type);
> The method should return time value as known by the Punctuator scheduler with
> the respective PunctuationType.
> The use-case is tracking of a process with timeout-based escalation.
> A transformer receives process events and in case of missing an event execute
> an action (emit message) after given escalation timeout (several stages). The
> initial message may already arrive with reference timestamp in the past and
> may trigger different action upon arrival depending on how far in the past it
> is.
> If the timeout should be computed against some further time only, Punctuator
> is perfectly sufficient. The problem is that I have to evaluate the current
> time-related state once the message arrives.
> I am using wall-clock time. Normally accessing System.currentTimeMillis() is
> sufficient, but it breaks in unit testing with TopologyTestDriver, where the
> app wall clock time is different from the system-wide one.
> To access the mentioned clock I am using reflection to access
> ProcessorContextImpl#task and then StreamTask#time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
