To HTTP chunk or not to chunk

Elastic Stack Elasticsearch
1

Hi,

http://www.elasticsearch.org/guide/en/elasticsearch/reference/1.4/modules-http.html
recommends NOT to use HTTP Chunking and to use Keep-Alive connections.
Yet, the HTTP chunking link there points
to http://en.wikipedia.org/wiki/Chunked_transfer_encoding , which implies
HTTP Chunking is good because it makes persistent connections possible.

Can anyone explain this apparent contradiction?

Thanks,
Otis

Monitoring * Alerting * Anomaly Detection * Centralized Log Management
Solr & Elasticsearch Support * http://sematext.com/

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/1d6408e5-4bca-4239-82fd-3c3df2388efb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

2

Hi Otis,
Elasticsearch makes use of asynchronous HTTP in order to scale well
with large numbers of connections. I cannot say for sure what's the
reason for putting this caveat into the Elasticsearch docs, but chunking
can show weird interactions with clients in an asynchronous scenario.
This could result in interleaved streams of data returned, which creates
extra complexity on the consumer side. While chunking clearly has
benefits for streaming data over HTTP, I don't see much of an advantage
with Elasticsearch where the size of responses won't be extremely large
or unbounded (due to window sizes/paging in result sets). Keep-alive
seems to be sufficient.

Let's see if anybody else has a better explanation... or better guess :slight_smile:

Best regards,
--Jürgen

On 16.11.2014 21:13, Otis Gospodnetic wrote:

Hi,

Elasticsearch Platform — Find real-time answers at scale | Elastic
recommends NOT to use HTTP Chunking and to use Keep-Alive connections.
Yet, the HTTP chunking link there points
to Chunked transfer encoding - Wikipedia , which
implies HTTP Chunking is good because it makes persistent connections
possible.

Can anyone explain this apparent contradiction?

Thanks,
Otis

Monitoring * Alerting * Anomaly Detection * Centralized Log Management
Solr & Elasticsearch Support * http://sematext.com/

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearch+unsubscribe@googlegroups.com
mailto:elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1d6408e5-4bca-4239-82fd-3c3df2388efb%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/1d6408e5-4bca-4239-82fd-3c3df2388efb%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

--

Mit freundlichen Grüßen/Kind regards/Cordialement vôtre/Atentamente/С
уважением
i.A. Jürgen Wagner
Head of Competence Center "Intelligence"
& Senior Cloud Consultant

Devoteam GmbH, Industriestr. 3, 70565 Stuttgart, Germany
Phone: +49 6151 868-8725, Fax: +49 711 13353-53, Mobile: +49 171 864 1543
E-Mail: juergen.wagner@devoteam.com
mailto:juergen.wagner@devoteam.com, URL: www.devoteam.de
http://www.devoteam.de/

Managing Board: Jürgen Hatzipantelis (CEO)
Address of Record: 64331 Weiterstadt, Germany; Commercial Register:
Amtsgericht Darmstadt HRB 6450; Tax Number: DE 172 993 071

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/54691208.5030404%40devoteam.com.
For more options, visit https://groups.google.com/d/optout.