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

"random_score", acceptable values for "seed" changed between 1.3 and 1.x #8267

Closed
iamjochem opened this issue Oct 29, 2014 · 2 comments

Comments

Projects
None yet
4 participants
@iamjochem
Copy link

commented Oct 29, 2014

hi there,

we have successfully been using integer representations of javascript Date objects for the "seed" property of the "random_function" scoring function, i.e. output of the following function:

function seedval(max_age) 
{
    var ma = max_age || 60000;
    return Math.ceil(+new Date() / ma) * ma;
}

which results in numbers like:

1414573200000

yesterday a colleague built and installed ES from source using the 1.x branch and stumbled upon the following error (it was definitely referring to the value set for "random_score.seed"!)

JsonParseException[Numeric value (1414573200000) out of range of int

NB: I am not looking for a fix as such (we decided to simply divide our generated seed values by 1000 thereby solving our immediate problem)

I am creating this issue because it just might be something that you would consider to be a regression, I have no idea which of the following might be true ... so by all means close this issue if you consider it to be irrelevant :)

  1. we are running ES as a 32bit process (not the case AFAICT)
  2. this is an intentional change/fix
  3. this is an unintentional change/bug - possibly related to upgrading (or introducing?) the Jackson lib, from which the parse error seems to originate.

hope this is of some use, thanks for reading!

@clintongormley

This comment has been minimized.

Copy link
Member

commented Oct 29, 2014

@rjernst could you take a look at this please? Looks like https://github.com/elasticsearch/elasticsearch/pull/7446/files changed from long to int.

@jpountz

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2014

I agree it would be nice to fix it as it is common to provide 64-bits values as seeds (eg. timestamps).

Maybe we could internally translate the 64-bits to 32-bits (since we only use 32-bits in practice) in a Long.hashCode fashion? Or maybe we could even allow the seed to be any string and internally use the 32-bits hash of this string as a seed. This could potentially be more user-friendly by allowing users to directly provide things like a session id?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.