[
https://issues.apache.org/jira/browse/KAFKA-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136395#comment-17136395
]
William Bottrell commented on KAFKA-10062:
------------------------------------------
[~mjsax] yes, this helps, thank you very much! I believe I found a good example
to look at in TopologyTestDriverTest.shouldPunctuateOnWallClockTime.
I'm working on the motivation for the kip and I want to make sure I really nail
it down. Is the motivation mainly for testing purposes? It seems like the
person writing the test can keep track of the system time since they are the
ones advancing it. Are we just providing an easy method that they can call, so
they don't need to keep track of it in their test? Or am I missing something
bigger?
Also, Piotr mentions, "where the app wall clock time is different from the
system-wide one". I don't know what this means because I thought they are the
same based on this definition "PunctuationType.WALL_CLOCK_TIME - uses system
time (the wall-clock time), which is advanced independent of whether new
messages arrive".
> 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)
