-
Notifications
You must be signed in to change notification settings - Fork 24.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ctx._now time seems to be incorrect #23169
Comments
@seang-es Can you please include the exact mappings, as well as the output when retrieving the updated document? |
Elasticsearch 5.2.0 + x-pack, macOS Sierra 10.12.3 (16D32), Oracle java version "1.8.0_65"
|
I think this is a bug. _now is set to nanotime in millis. |
I found the bug. We currently use |
Oops sorry Simon, I guess that's what you were trying to say. :) |
In update scripts, `ctx._now` uses the same milliseconds value used by the rest of the system to caluclate deltas. However, that time is not actually epoch milliseconds, as it is derived from `System.nanoTime()`. This change reworks the estimated time thread in ThreadPool which this time is based on to make available both the relative time, as well as absolute milliseconds (epoch) which may be used with calendar system. It also renames the EstimatedTimeThread to a more apt CachedTimeThread. closes elastic#23169
…nds (#23175) In update scripts, `ctx._now` uses the same milliseconds value used by the rest of the system to calculate deltas. However, that time is not actually epoch milliseconds, as it is derived from `System.nanoTime()`. This change reworks the estimated time thread in ThreadPool which this time is based on to make available both the relative time, as well as absolute milliseconds (epoch) which may be used with calendar system. It also renames the EstimatedTimeThread to a more apt CachedTimeThread. closes #23169
…nds (#23175) In update scripts, `ctx._now` uses the same milliseconds value used by the rest of the system to calculate deltas. However, that time is not actually epoch milliseconds, as it is derived from `System.nanoTime()`. This change reworks the estimated time thread in ThreadPool which this time is based on to make available both the relative time, as well as absolute milliseconds (epoch) which may be used with calendar system. It also renames the EstimatedTimeThread to a more apt CachedTimeThread. closes #23169
…nds (#23175) In update scripts, `ctx._now` uses the same milliseconds value used by the rest of the system to calculate deltas. However, that time is not actually epoch milliseconds, as it is derived from `System.nanoTime()`. This change reworks the estimated time thread in ThreadPool which this time is based on to make available both the relative time, as well as absolute milliseconds (epoch) which may be used with calendar system. It also renames the EstimatedTimeThread to a more apt CachedTimeThread. closes #23169
To repro:
Create a document, then update it as follows:
In the results we're seeing, epochms is correct, but timestamp_now seems to be a random time. The ctx._now time is consistently increasing, but on various different nodes it has returned times ranging from 2003 to 2019.
The text was updated successfully, but these errors were encountered: