# Problem with BIG\_INTEGERs **URL:** \ **Category:** Elasticsearch\ **Created:** [January 9, 2012, 7:46pm UTC](https://discuss.elastic.co/t/problem-with-big-integers/6330 "2012-01-09T19:46:42Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![drew\_letcher](https://avatars.discourse-cdn.com/v4/letter/d/b3f665/32.png) [@drew\_letcher](https://discuss.elastic.co/u/drew_letcher)\ **Post date:** [January 9, 2012, 7:46pm UTC](https://discuss.elastic.co/t/problem-with-big-integers/6330/1 "2012-01-09T19:46:42Z")
Our application creates a 64-bit hash id that is stored in an ElastichSearch long field. We have some problems retrieving documents. Retrieving "\_source" works. Trying to retrieve any specific field(s) causes the following error from some shards: failures: [ ``` { status: 500 reason: RemoteTransportException[[dev-nosql-h03][inet[/ ``` 172.22.59.53:9300]][search/phase/fetch/id]]; nested: ElasticSearchParseException[failed to parse / load source]; nested: ElasticSearchIllegalStateException[No matching token for number\_type [BIG\_INTEGER]]; } Here are some example integers that cause the issue: 0xB8F136795037CFD0 0x9BE37E6093517F88 Our application only needs 48bits hash ID's. I reindex everything with 48bit values and the problem went away. ElasticSearch 0.18.6. The index stores \_source. It does not store any individual fields. ---
**Author:** ![drew\_letcher](https://avatars.discourse-cdn.com/v4/letter/d/b3f665/32.png) [@drew\_letcher](https://discuss.elastic.co/u/drew_letcher)\ **Post date:** [January 9, 2012, 7:49pm UTC](https://discuss.elastic.co/t/problem-with-big-integers/6330/2 "2012-01-09T19:49:25Z")
I assume it is a problem reading an unsigned value into a signed variable. ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [January 9, 2012, 7:58pm UTC](https://discuss.elastic.co/t/problem-with-big-integers/6330/3 "2012-01-09T19:58:29Z")
Can you create a recreation? Even when indexing, if it works, your numbers will loose resolution if they are too big since they are converted to a long number. On Mon, Jan 9, 2012 at 9:49 PM, drew.letcher \< [drew.letcher@interactivedata.com](mailto:drew.letcher@interactivedata.com)\> wrote: > I assume it is a problem reading an unsigned value into a signed > variable. ---
**Author:** ![drew\_letcher](https://avatars.discourse-cdn.com/v4/letter/d/b3f665/32.png) [@drew\_letcher](https://discuss.elastic.co/u/drew_letcher)\ **Post date:** [January 10, 2012, 12:08am UTC](https://discuss.elastic.co/t/problem-with-big-integers/6330/4 "2012-01-10T00:08:59Z")
I'm a C++ programmer using the HTTP interface. I didn't realize that Java doesn't have unsigned integers. I understand what you are saying. Java is not able to parse the value so that field would not be indexed. I can see them in the \_source, because that is the exact json text I sent. A search asking for specifc fields causes the \_source to be parsed which generates the Java error. If I wanted 64 bit hash ID's I would have to cast the unsigned value to a signed value before passing it to ElasticSearch. Mystery solved. ---
**Author:** ![calc](https://avatars.discourse-cdn.com/v4/letter/c/ecc23a/32.png) [@calc](https://discuss.elastic.co/u/calc)\ **Post date:** [May 25, 2012, 11:24pm UTC](https://discuss.elastic.co/t/problem-with-big-integers/6330/5 "2012-05-25T23:24:15Z")
Actually I have the same problem when running ES 0.19.3. I also have 64-bit hashed id for many different attributes in our documents, but it seems ES can't automatically recognize these id's: dxu@ubuntu:~$ curl -s -S -XPUT '[http://localhost:9200/test/test1/1](http://localhost:9200/test/test1/1)' -d '{"id": 11516060740533628129}' {"error":"ElasticSearchIllegalStateException[No matching token for number\_type [BIG\_INTEGER]]","status":500} On Monday, January 9, 2012 2:58:29 PM UTC-5, kimchy wrote: > Can you create a recreation? Even when indexing, if it works, your numbers > will loose resolution if they are too big since they are converted to a > long number. > > On Mon, Jan 9, 2012 at 9:49 PM, drew.letcher \< > [drew.letcher@interactivedata.com](mailto:drew.letcher@interactivedata.com)\> wrote: > > > I assume it is a problem reading an unsigned value into a signed > > variable. ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [May 26, 2012, 3:02pm UTC](https://discuss.elastic.co/t/problem-with-big-integers/6330/6 "2012-05-26T15:02:01Z")
Thats because ES supporting 64bit signed integers, just send it as a string in this case. On Sat, May 26, 2012 at 1:24 AM, calc [donghua@gmail.com](mailto:donghua@gmail.com) wrote: > Actually I have the same problem when running ES 0.19.3. I also have > 64-bit hashed id for many different attributes in our documents, but it > seems ES can't automatically recognize these id's: > > dxu@ubuntu:~$ curl -s -S -XPUT '[http://localhost:9200/test/test1/1](http://localhost:9200/test/test1/1)' -d > '{"id": 11516060740533628129}' > {"error":"ElasticSearchIllegalStateException[No matching token for > number\_type [BIG\_INTEGER]]","status":500} > > On Monday, January 9, 2012 2:58:29 PM UTC-5, kimchy wrote: > > > Can you create a recreation? Even when indexing, if it works, your > > numbers will loose resolution if they are too big since they are converted > > to a long number. > > > > On Mon, Jan 9, 2012 at 9:49 PM, drew.letcher \< > > drew.letcher@interactivedata.\*\*com [drew.letcher@interactivedata.com](mailto:drew.letcher@interactivedata.com)\>wrote: > > > > > I assume it is a problem reading an unsigned value into a signed > > > variable. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:26am UTC](https://discuss.elastic.co/t/problem-with-big-integers/6330/7 "2017-07-06T03:26:48Z")