Empty response when search through too many indices

My situation is:

  • Elasticsearch 1.7.3 (didn't migrate to new version cause of complexity of app modifications but it's already planned)
  • Much indices on different nodes (through tribe node)
  • Each index name has structure like index_type_prefilter1_prefilter2
  • prefilter2 can be made on level of objects properties while prefilter1 can't

I need to search objects that satisfy several conditions like:
all objects which are prefilter_1 in [x1,x2] and `prefilter_2 in [y1,y2,y3]
I don't want to search through all indices (there are many of them, so dropping most will greatly affect the speed) so I prepared list of indices:

        "type_x1_y1", "type_x1_y2", "type_x1_y3",
        "type_x2_y1", "type_x2_y2", "type_x2_y3",

So the problem is when I try to execute request to all that indices (aprox. 200) I got "curl: (52) Empty reply from server" and in my opinion the problem is exactly in indices count in request cause the same request with less indices returned correct response.

 curl -XPOST '**indices_list**/objects/_search?ignore_unavailable=true'  -d '{"query":{"bool":{"must":{"term":{"79":"300"}}}},"size":"10"}'`

I can't check this situation on last version of elasticsearch.
It'll be great if I can use regex in indices (I know about '*' and '-') smth like type_[x1,x2]_[y1,y2,y3].

I see few solutions to overcome this:

  1. Decrease indices count with mask like type_x1_*,type_x2_* and filter by second property in request, but where is slightly possibility that someday properties count became too big.
  2. Divide request into several by indices and then merge the responses.

Do anyone know about this problem? Maybe there are some quantity limits, request length or something else? Thx.

Do you see any errors in the elasticsearch log files?

Yes, sorry about that forgot to attach them:
[WARN ][http.netty ] [Mother Earth] Caught exception while handling client http traffic, closing connection [id: 0x1433e26c, / => /] java.lang.IllegalArgumentException: invalid version format:indices_list/OBJECTS/_SEARCH?IGNORE_UNAVAILABLE=TRUE HTTP/1.1

Which client are you using and what version of the client? Also, 1.7.3 is not even obsolete it's basically dangerous software to run at the moment.

If you mean which client I use in app they are 'elasticsearch.Net' and 'Nest'.
I think that the problem isn't on the client side, CentOS 'curl' tool response with 'empty responce' and nest return something like 'connection closed by remote...'

Also, 1.7.3 is not even obsolete it's basically dangerous software to run at the moment.

I know that there is elasticsearch 7.0 already, but its too difficult to migrate to new version now.

Could you explain why it's dangerous to use? (it'll be great if you provide some links, if not i'll try to find out it myself)

How does the curl request look like?

Be sure to use only the 1.x versions of these clients with Elasticsearch 1.7.3 - later client versions are not compatible. Do note however that similar to Elasticsearch 1.7.3, Nest and Elasticsearch 1.x are not longer supported.

Communication between clients (elasticsearch.net & nest) and elasticsearch cluster already works long enough and I don't have any major problems with it. For now I had to start optimizing the query and it doesn't work nor through clients nor through simple 'POST' (curl was mentioned upper, I only changes indices to '**indices_list**' due to save space in post)

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.