Skip to content
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

Closed
seang-es opened this issue Feb 14, 2017 · 5 comments · Fixed by #23175
Closed

ctx._now time seems to be incorrect #23169

seang-es opened this issue Feb 14, 2017 · 5 comments · Fixed by #23175

Comments

@seang-es
Copy link

To repro:

Create a document, then update it as follows:

POST my-index/my-type/1/_update
{
   "script" : {
       "inline": "ctx._source.timestamp_now = ctx._now; ctx._source.epochms = new Date().getTime();",
       "lang": "painless"
   },
   "upsert" : {
       "foo":"bar"
   }
}

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.

@rjernst
Copy link
Member

rjernst commented Feb 14, 2017

@seang-es Can you please include the exact mappings, as well as the output when retrieving the updated document?

@jpcarey
Copy link
Contributor

jpcarey commented Feb 14, 2017

Elasticsearch 5.2.0 + x-pack, macOS Sierra 10.12.3 (16D32), Oracle java version "1.8.0_65"

POST t/t/1
{
  "foo": "bar"
}
POST t/t/1/_update
{
  "script": {
    "inline": "ctx._source.timestamp_now = ctx._now; ctx._source.epochms = new Date().getTime();",
    "lang": "painless"
  },
  "upsert": {
    "foo": "bar2"
  }
}

GET t/t/1 Response:

{
  "_index": "t",
  "_type": "t",
  "_id": "1",
  "_version": 4,
  "found": true,
  "_source": {
    "foo": "bar",
    "timestamp_now": 1206909990,
    "epochms": 1487111464024
  }
}

GET t/_mapping Response:

{
  "t": {
    "mappings": {
      "t": {
        "properties": {
          "epochms": {
            "type": "long"
          },
          "foo": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "timestamp_now": {
            "type": "long"
          }
        }
      }
    }
  }
}

@s1monw
Copy link
Contributor

s1monw commented Feb 14, 2017

I think this is a bug. _now is set to nanotime in millis.

@rjernst
Copy link
Member

rjernst commented Feb 15, 2017

I found the bug. We currently use System.nanoTime() and convert that to milliseconds, but that is not milliseconds since epoch. This was changed about 1.5 years ago to avoid System.currentTimeMillis() from going backwards (see #11626). We either need to go back to System.currentTimeMillis(), or look at how to protecting from negative time diffs differently.

@rjernst
Copy link
Member

rjernst commented Feb 15, 2017

Oops sorry Simon, I guess that's what you were trying to say. :)

rjernst added a commit to rjernst/elasticsearch that referenced this issue Feb 15, 2017
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
rjernst added a commit that referenced this issue Feb 22, 2017
…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
rjernst added a commit that referenced this issue Feb 23, 2017
…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
rjernst added a commit that referenced this issue Feb 23, 2017
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants