Support querying more indices than 4096 bytes-worth

[jordansissel]

Background: Most logstash users use the default "logstash-YYYY.MM.dd" index naming scheme. Some use hourly. The main way to access Elasticsearch in this use case is often Kibana.

In Elasticsearch 1.3.1 (and older, probably), aborts a query if the request line itself is longer than 4096 bytes, which limites the default logstash use case to about 195 days of querying (each day is 20 bytes of index name, plus comma, 4096 / 21 = 195.04;ignoring remainder of request line)
For hourly partitions, this limits you to 170 indices (7 days of data).

It would be lovely if users could still use these partitioning schemes and query more than 195 days (or 7 days, for hourly indexes) of data in a single query.

Related: elastic/kibana#1406

[spinscale]

I think you can change this behaviour by setting http.netty.max_initial_line_length to a ByteSizeValue like 10kb, default is 4kb

[clintongormley]

Of course there may be a proxy in the way with a similar limitation. However, there are a few ways of handling this already:

1. Use a multi-search request, in which case the index names are in the body
2. Use wildcards: logstash-2012*,logstash-2013*,logstash-2014-01*,logstash-2014-02* etc
3. Use aliases

[spinscale]

bumping @clintongormley, any action to take here on ES side?

[clintongormley]

@spinscale I don't think so, unless @jordansissel disagrees?

[jordansissel]

+1 I don't believe there's any action to take, given:

• Users can tune this for their situation
• Kibana 4 solves my original problem (Support queries against too many indices kibana#1406)
• Any default value may not be a "great" default value, so the current default seems reasonable :)