# Curiousty about http asynchronous **URL:** \ **Category:** Elasticsearch\ **Created:** [December 9, 2015, 1:48am UTC](https://discuss.elastic.co/t/curiousty-about-http-asynchronous/36685 "2015-12-09T01:48:32Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![makeyang](https://avatars.discourse-cdn.com/v4/letter/m/f05b48/32.png) [@makeyang](https://discuss.elastic.co/u/makeyang)\ **Post date:** [December 9, 2015, 1:48am UTC](https://discuss.elastic.co/t/curiousty-about-http-asynchronous/36685/1 "2015-12-09T01:48:32Z")
es reference doc has this sentence: The http mechanism is completely asynchronous in nature, meaning that there is no blocking thread waiting for a response. but when I use http bulk index API, it will wait for each doc index status. so what does the asynchronous in doc mean? ---
**Author:** ![jasontedor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jasontedor/32/66992_2.png) [@jasontedor](https://discuss.elastic.co/u/jasontedor)\ **Post date:** [December 9, 2015, 2:10am UTC](https://discuss.elastic.co/t/curiousty-about-http-asynchronous/36685/2 "2015-12-09T02:10:53Z")
> [@makeyang](#): > > so what does the asynchronous in doc mean? It refers to the server-side where Elasticsearch uses non-blocking I/O to manage incoming connections. When a request comes in, it is asynchronously handed off to a worker thread which means that the receiving thread can immediately return to service another client request. Eventually, the worker thread will complete its work and will execute a callback to get the response back out to the client. This is what is meant by "asynchronous" and this is how Elasticsearch is able to _concurrently_ handle a large number of requests without blocking request threads. This is in complete opposition to a server that uses blocking I/O to manage incoming connections. In a typical "prefork" model (e.g., Apache `mpm_prefork_module`), a fixed number of threads (or child processes) will be preforked and then wait for client requests to come in. When a client request comes in, one of these workers will service the request from end to end (request to response). If all of these preforked workers are busy servicing client requests, too bad. Think of a typical bank with a fixed number of teller windows; when every teller window is occupied, everyone else in line is blocked from even having their request started on. If instead a bank used a non-blocking model, tellers would take requests from clients, hand off the request to someone else and immediately move on to the next client. At some point, a worker would complete a client request, hand it back to a teller who would then forward the completed request (cash, receipt, etc.) to the appropriate client. ---
**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\ **Post date:** [December 9, 2015, 2:24am UTC](https://discuss.elastic.co/t/curiousty-about-http-asynchronous/36685/3 "2015-12-09T02:24:57Z")
> [@jasontedor](#): > > it is asynchronously handed off to a worker thread which means that the receiving thread can immediately return to service another client request This is what it means. I was getting confused by all the other non-blocking stuff. All that other stuff I said about non-blocking internal requests is true, but its not what that sentence was talking about. ---
**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\ **Post date:** [December 9, 2015, 2:25am UTC](https://discuss.elastic.co/t/curiousty-about-http-asynchronous/36685/4 "2015-12-09T02:25:50Z")
Its a reference to the way elasticsearch is written. When elasticsearch sends requests to itself around the cluster it never blocks any of its threads. Instead it returns the thread to the thread pool and checks a new one out when the response comes back. Requests can flow around the cluster pretty fluidly. Searches typically run two requests against the data nodes. Index requests hit the data node with the primary shard first then are pushed to the replica shards, etc. The node that actually handles the http is the same way. Its important that elasticsearch works this way because it means it can handle lots of requests. Threads are expensive and blocking them is wasteful. Elasticsearch does lots of other important stuff to scale and the guide does call all of them out but it calls this out because its one of the more important things. ---
**Author:** ![makeyang](https://avatars.discourse-cdn.com/v4/letter/m/f05b48/32.png) [@makeyang](https://discuss.elastic.co/u/makeyang)\ **Post date:** [December 10, 2015, 2:53am UTC](https://discuss.elastic.co/t/curiousty-about-http-asynchronous/36685/5 "2015-12-10T02:53:50Z")
got it. thanks a lot ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 11:32pm UTC](https://discuss.elastic.co/t/curiousty-about-http-asynchronous/36685/6 "2017-07-05T23:32:10Z")