[
https://issues.apache.org/jira/browse/KAFKA-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136232#comment-17136232
]
Matthias J. Sax commented on KAFKA-10062:
-----------------------------------------
The testing is done using `TopologyTestDriver` (cf
[https://kafka.apache.org/25/documentation/streams/developer-guide/testing.html])
– the test driver mocks wall-clock time and allows users to manipulate
wall-clock time to control when wall-clock-time-based punctuation should fire.
However, the mocked wall-clock time is not exposed via the `context`.
Note, that internally, all code alway used `Time` interface if it needs access
to system time. In a read deployment this will translate to system time, while
the test driver switches the implementation to use `MockTime`.
Does this help?
> 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)
