[
https://issues.apache.org/jira/browse/FLINK-23960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17407526#comment-17407526
]
Anton Kalashnikov edited comment on FLINK-23960 at 8/31/21, 5:01 PM:
---------------------------------------------------------------------
The cause of this problem is https://issues.apache.org/jira/browse/FLINK-23208.
After these changes, if we have processingTime equal to currentTime the result
time will be 1 ms, but if we have procesingTime less than currentTime the
result will be 0. So if we have a sequence like that:
{noformat}
registerTimer(currentTime, ...)
registerTimer(currentTime-1, ...)
{noformat}
According to the test, we should execute it in order of registration but in
fact, we reorder it because of the reason which I described before.
I personally don't understand the semantic of
ProcessingTimeServiceUtil#getProcessingTimeDelay and why we should increase
processing time on 1 ms(especially why we should do it with `0`). So maybe,
[~pnowojski] or [~wind_ljy] can you help with that? I mean it should be simple
if we are sure about changes in FLINK-23208 then we should change the
`checkScheduledTimestamps` test according to the new semantic.
P.S. It will be nice if you explain or give me some link with an explanation
about why `A watermark T says we won't see elements in the future with a
timestamp smaller or equal to T` and why processing time service should
following the same rule.
was (Author: akalashnikov):
The cause of this problem is https://issues.apache.org/jira/browse/FLINK-23208.
After these changes, if we have processingTime equal to currentTime the result
time will be 1 ms, but if we have procesingTime less than currentTime the
result will be 0. So if we have a sequence like that:
```
registerTimer(currentTime, ...)
registerTimer(currentTime-1, ...)
```
According to the test, we should execute it in order of registration but in
fact, we reorder it because of the reason which I described before.
I personally don't understand the semantic of
ProcessingTimeServiceUtil#getProcessingTimeDelay and why we should increase
processing time on 1 ms(especially why we should do it with `0`). So maybe,
[~pnowojski] or [~wind_ljy] can you help with that? I mean it should be simple
if we are sure about changes in FLINK-23208 then we should change the
`checkScheduledTimestamps` test according to the new semantic.
P.S. It will be nice if you explain or give me some link with an explanation
about why `A watermark T says we won't see elements in the future with a
timestamp smaller or equal to T` and why processing time service should
following the same rule.
> StreamTaskTimerTest.checkScheduledTimestamps fails on azure
> -----------------------------------------------------------
>
> Key: FLINK-23960
> URL: https://issues.apache.org/jira/browse/FLINK-23960
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Task
> Affects Versions: 1.14.0, 1.15.0
> Reporter: Xintong Song
> Priority: Critical
> Labels: test-stability
> Fix For: 1.14.0, 1.15.0
>
>
> https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=22770&view=logs&j=f0ac5c25-1168-55a5-07ff-0e88223afed9&t=50bf7a25-bdc4-5e56-5478-c7b4511dde53&l=10736
> {code}
> Aug 24 22:32:06 [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0,
> Time elapsed: 1.421 s <<< FAILURE! - in
> org.apache.flink.streaming.runtime.operators.StreamTaskTimerTest
> Aug 24 22:32:06 [ERROR] checkScheduledTimestamps Time elapsed: 1.372 s <<<
> FAILURE!
> Aug 24 22:32:06 java.lang.AssertionError: expected:<1> but was:<0>
> Aug 24 22:32:06 at org.junit.Assert.fail(Assert.java:89)
> Aug 24 22:32:06 at
> org.apache.flink.streaming.runtime.operators.StreamTaskTimerTest.verifyNoException(StreamTaskTimerTest.java:166)
> Aug 24 22:32:06 at
> org.apache.flink.streaming.runtime.operators.StreamTaskTimerTest.checkScheduledTimestamps(StreamTaskTimerTest.java:129)
> Aug 24 22:32:06 at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Aug 24 22:32:06 at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> Aug 24 22:32:06 at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Aug 24 22:32:06 at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> Aug 24 22:32:06 at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> Aug 24 22:32:06 at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> Aug 24 22:32:06 at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> Aug 24 22:32:06 at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> Aug 24 22:32:06 at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> Aug 24 22:32:06 at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> Aug 24 22:32:06 at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
> Aug 24 22:32:06 at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
> Aug 24 22:32:06 at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> Aug 24 22:32:06 at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
