EQL: correct time accounting for an intermediary response #75804
Conversation
This corrects the accounting of answer time reported in "took" attribute of an intermediary EQL async response. This has been reported as a negative value, since the delta mixes wall-clock time with VM time. (The confusion is favoured by Task#getStartTime() returning a wall-clock time, while Task#getStartTimeNanos() VM's time.)
...ck/plugin/eql/src/main/java/org/elasticsearch/xpack/eql/plugin/TransportEqlSearchAction.java
Outdated
Show resolved
Hide resolved
Correct the accounting as the diff between VM's time and task's creation time.
If search task is set in under 1ms, the test will complete with an accounting of 0ms.
|
@elasticmachine update branch |
elasticmachine
added
the
Team:QL (Deprecated)
|
Pinging @elastic/es-ql (Team:QL) |
Luegg
left a comment
Luegg
left a comment
There was a problem hiding this comment.
lgtm 👍
Just wondering whether we have a general preference for the JVM time? Otherwise, System.currentTimeMillis() - task.getStartTime() might also be an option?
bpintea
added
the
auto-backport
Switch to millis math.
You're right, the original code was doing millis math in the first place. I guess nanos math makes sense to more accurately differentiate between 0 and 1ms, but don't think this is that relevant in this case. Applied your suggestion. |
astefan
left a comment
astefan
left a comment
There was a problem hiding this comment.
LGTM
This is fixing an annoying issue that I noticed myself as well. Thanks for addressing it.
|
@elasticmachine run elasticsearch-ci/part-2 |
I don't think it is a general preference, but for calculating elapsed time we are trying to go with |
Swtich back to converted nanos-accounting.
|
@elasticmachine update branch |
|
@elasticmachine run elasticsearch-ci/docs |
|
Thanks for the explanations, @imotov, reverted to your proposal. |
) This corrects the accounting of answer time reported in "took" attribute of an intermediary EQL async response. This has been reported as a negative value, since the delta mixes wall-clock time with VM time. (The confusion is favoured by Task#getStartTime() returning a wall-clock time, while Task#getStartTimeNanos() VM's time.)
) This corrects the accounting of answer time reported in "took" attribute of an intermediary EQL async response. This has been reported as a negative value, since the delta mixes wall-clock time with VM time. (The confusion is favoured by Task#getStartTime() returning a wall-clock time, while Task#getStartTimeNanos() VM's time.)
…76000) This corrects the accounting of answer time reported in "took" attribute of an intermediary EQL async response. This has been reported as a negative value, since the delta mixes wall-clock time with VM time. (The confusion is favoured by Task#getStartTime() returning a wall-clock time, while Task#getStartTimeNanos() VM's time.) Co-authored-by: Bogdan Pintea <[email protected]>
…76001) This corrects the accounting of answer time reported in "took" attribute of an intermediary EQL async response. This has been reported as a negative value, since the delta mixes wall-clock time with VM time. (The confusion is favoured by Task#getStartTime() returning a wall-clock time, while Task#getStartTimeNanos() VM's time.) Co-authored-by: Bogdan Pintea <[email protected]>
) This corrects the accounting of answer time reported in "took" attribute of an intermediary EQL async response. This has been reported as a negative value, since the delta mixes wall-clock time with VM time. (The confusion is favoured by Task#getStartTime() returning a wall-clock time, while Task#getStartTimeNanos() VM's time.)
7 participants
This corrects the accounting of answer time reported in "took" attribute
of an intermediary EQL async response. This has been reported as a
negative value, since the delta mixes wall-clock time with VM time.
(The confusion is favoured by Task#getStartTime() returning a wall-clock
time, while Task#getStartTimeNanos() VM's time.)
Closes #75825.