Problem after 0.16.0 upgrade


(Jan Fiedler) #1

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).


(Shay Banon) #2

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.

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: 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).


(Jan Fiedler) #3

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

On Apr 29, 11:25 pm, Shay Banon 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.

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: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).


(Shay Banon) #4

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 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.

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: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).


(system) #5