# Problem after 0.16.0 upgrade

**URL:** <https://discuss.elastic.co/t/problem-after-0-16-0-upgrade/4314>\
**Category:** Elasticsearch\
**Created:** [April 29, 2011, 7:32am UTC](https://discuss.elastic.co/t/problem-after-0-16-0-upgrade/4314 "2011-04-29T07:32:53Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jan\_Fiedler](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jan_fiedler/32/2518_2.png) [@Jan\_Fiedler](https://discuss.elastic.co/u/Jan_Fiedler)\
**Post date:** [April 29, 2011, 7:32am UTC](https://discuss.elastic.co/t/problem-after-0-16-0-upgrade/4314/1 "2011-04-29T07:32:53Z")

</div>

I have a test suite testing search behavior of my code running on top  
of Elastic Search (Java API). After updating to 0.16.0 some tests  
fail. Going back to 0.15.2 everything is green again. It is therefore  
very likely that the failures are caused by the new ES version.

The problem seems to be limited to field names that only differ by a  
numeric character (like 'field1' and 'field2'). It also seems related  
to ES node state as the results change if I restart the node and  
reorder the queries. I spent a day trying to come up with a pure curl  
reproduction without success. This makes me think that the problem  
must be limited to the Java API. I therefore created a Java test case  
that runs my queries via transport client against a running ES 0.16.0  
node. I also gisted a curl recreation of the index setup / type  
mapping / sample documents. Find the gist here: [https://gist.github.com/947984](https://gist.github.com/947984)

The example is a little verbose. I tried to make it smaller but the  
test then went green. I therefore believe that the problem has to do  
with the particular field names I am using (maybe depends on hash  
codes of field names).

---

<div class="post-metadata">

**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:** [April 29, 2011, 9:25pm UTC](https://discuss.elastic.co/t/problem-after-0-16-0-upgrade/4314/2 "2011-04-29T21:25:36Z")

</div>

Heya,

Yea, seems like a bug in Smile format (which is used to generate the search request by default), I opened an issue with a pure jackson recreation here: [http://jira.codehaus.org/browse/JACKSON-564](http://jira.codehaus.org/browse/JACKSON-564).

For now, until its fixed, you can set somewhere globally in your APP the content type that will be used to generate search requests by setting:

Requests.CONTENT\_TYPE = XContentType.JSON;

(note the fugly static here).

-shay.banon  
On Friday, April 29, 2011 at 10:32 AM, Jan Fiedler wrote:

> I have a test suite testing search behavior of my code running on top  
> of Elastic Search (Java API). After updating to 0.16.0 some tests  
> fail. Going back to 0.15.2 everything is green again. It is therefore  
> very likely that the failures are caused by the new ES version.
> 
> The problem seems to be limited to field names that only differ by a  
> numeric character (like 'field1' and 'field2'). It also seems related  
> to ES node state as the results change if I restart the node and  
> reorder the queries. I spent a day trying to come up with a pure curl  
> reproduction without success. This makes me think that the problem  
> must be limited to the Java API. I therefore created a Java test case  
> that runs my queries via transport client against a running ES 0.16.0  
> node. I also gisted a curl recreation of the index setup / type  
> mapping / sample documents. Find the gist here: [Curl / Java API Recreation of Elastic Search 0.16.0 Problem · GitHub](https://gist.github.com/947984)
> 
> The example is a little verbose. I tried to make it smaller but the  
> test then went green. I therefore believe that the problem has to do  
> with the particular field names I am using (maybe depends on hash  
> codes of field names).

---

<div class="post-metadata">

**Author:** ![Jan\_Fiedler](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jan_fiedler/32/2518_2.png) [@Jan\_Fiedler](https://discuss.elastic.co/u/Jan_Fiedler)\
**Post date:** [May 2, 2011, 7:03am UTC](https://discuss.elastic.co/t/problem-after-0-16-0-upgrade/4314/3 "2011-05-02T07:03:05Z")

</div>

Thanks Shay. The workaround you provided works like a charm.

On Apr 29, 11:25 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:

> Heya,
> 
> Yea, seems like a bug in Smile format (which is used to generate the search request by default), I opened an issue with a pure jackson recreation here:[http://jira.codehaus.org/browse/JACKSON-564](http://jira.codehaus.org/browse/JACKSON-564).
> 
> For now, until its fixed, you can set somewhere globally in your APP the content type that will be used to generate search requests by setting:
> 
> Requests.CONTENT\_TYPE = XContentType.JSON;
> 
> (note the fugly static here).
> 
> -shay.banon
> 
> On Friday, April 29, 2011 at 10:32 AM, Jan Fiedler wrote:
> 
> > I have a test suite testing search behavior of my code running on top  
> > of Elastic Search (Java API). After updating to 0.16.0 some tests  
> > fail. Going back to 0.15.2 everything is green again. It is therefore  
> > very likely that the failures are caused by the new ES version.
> 
> > The problem seems to be limited to field names that only differ by a  
> > numeric character (like 'field1' and 'field2'). It also seems related  
> > to ES node state as the results change if I restart the node and  
> > reorder the queries. I spent a day trying to come up with a pure curl  
> > reproduction without success. This makes me think that the problem  
> > must be limited to the Java API. I therefore created a Java test case  
> > that runs my queries via transport client against a running ES 0.16.0  
> > node. I also gisted a curl recreation of the index setup / type  
> > mapping / sample documents. Find the gist here:[Curl / Java API Recreation of Elastic Search 0.16.0 Problem · GitHub](https://gist.github.com/947984)
> 
> > The example is a little verbose. I tried to make it smaller but the  
> > test then went green. I therefore believe that the problem has to do  
> > with the particular field names I am using (maybe depends on hash  
> > codes of field names).

---

<div class="post-metadata">

**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 2, 2011, 10:23am UTC](https://discuss.elastic.co/t/problem-after-0-16-0-upgrade/4314/4 "2011-05-02T10:23:47Z")

</div>

Great. I will ping once the issue is fixed and integrated into elasticsearch.  
On Monday, May 2, 2011 at 10:03 AM, Jan Fiedler wrote:

> Thanks Shay. The workaround you provided works like a charm.
> 
> On Apr 29, 11:25 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> 
> > Heya,
> > 
> > Yea, seems like a bug in Smile format (which is used to generate the search request by default), I opened an issue with a pure jackson recreation here:[http://jira.codehaus.org/browse/JACKSON-564](http://jira.codehaus.org/browse/JACKSON-564).
> > 
> > For now, until its fixed, you can set somewhere globally in your APP the content type that will be used to generate search requests by setting:
> > 
> > Requests.CONTENT\_TYPE = XContentType.JSON;
> > 
> > (note the fugly static here).
> > 
> > -shay.banon
> > 
> > On Friday, April 29, 2011 at 10:32 AM, Jan Fiedler wrote:
> > 
> > > I have a test suite testing search behavior of my code running on top  
> > > of Elastic Search (Java API). After updating to 0.16.0 some tests  
> > > fail. Going back to 0.15.2 everything is green again. It is therefore  
> > > very likely that the failures are caused by the new ES version.
> > 
> > > The problem seems to be limited to field names that only differ by a  
> > > numeric character (like 'field1' and 'field2'). It also seems related  
> > > to ES node state as the results change if I restart the node and  
> > > reorder the queries. I spent a day trying to come up with a pure curl  
> > > reproduction without success. This makes me think that the problem  
> > > must be limited to the Java API. I therefore created a Java test case  
> > > that runs my queries via transport client against a running ES 0.16.0  
> > > node. I also gisted a curl recreation of the index setup / type  
> > > mapping / sample documents. Find the gist here:[Curl / Java API Recreation of Elastic Search 0.16.0 Problem · GitHub](https://gist.github.com/947984)
> > 
> > > The example is a little verbose. I tried to make it smaller but the  
> > > test then went green. I therefore believe that the problem has to do  
> > > with the particular field names I am using (maybe depends on hash  
> > > codes of field names).

---

<div class="post-metadata">

**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, 4:07am UTC](https://discuss.elastic.co/t/problem-after-0-16-0-upgrade/4314/5 "2017-07-06T04:07:10Z")

</div>

Closed on July 6, 2017, 4:07am UTC