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
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).
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.
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
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).
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.
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
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).
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.
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
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).
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.