# Clean shutdown of an Elasticsearch node **URL:** \ **Category:** Elasticsearch\ **Created:** [June 8, 2012, 5:07am UTC](https://discuss.elastic.co/t/clean-shutdown-of-an-elasticsearch-node/8016 "2012-06-08T05:07:41Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Dan\_Everton](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dan_everton/32/1865_2.png) [@Dan\_Everton](https://discuss.elastic.co/u/Dan_Everton)\ **Post date:** [June 8, 2012, 5:07am UTC](https://discuss.elastic.co/t/clean-shutdown-of-an-elasticsearch-node/8016/1 "2012-06-08T05:07:41Z")
I've read the documentation for the node shutdown API ([http://www.elasticsearch.org/guide/reference/api/admin-cluster-nodes-shutdown.html](http://www.elasticsearch.org/guide/reference/api/admin-cluster-nodes-shutdown.html)) and it's not clear to me what happens to inflight requests when a shutdown is requested? Ideally the node would reject new requests (or direct them to the other cluster members), allow existing requests to finish, and then shutdown. There's a delay parameter there which might help, but it still doesn't say if new requests are blocked. Cheers, Dan ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [June 10, 2012, 9:48pm UTC](https://discuss.elastic.co/t/clean-shutdown-of-an-elasticsearch-node/8016/2 "2012-06-10T21:48:21Z")
The shutdown will not wait for current requests to finish. If they are coming from other nodes in the cluster, then it will properly fail over to other nodes, if its from a "client" directly, then a socket closed will probably be thrown. On Fri, Jun 8, 2012 at 7:07 AM, Dan Everton [dan@iocaine.org](mailto:dan@iocaine.org) wrote: > I've read the documentation for the node shutdown API ( > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/admin-cluster-nodes-shutdown.html)) > and it's not clear to me what happens to inflight requests when a shutdown > is requested? Ideally the node would reject new requests (or direct them to > the other cluster members), allow existing requests to finish, and then > shutdown. > > There's a delay parameter there which might help, but it still doesn't say > if new requests are blocked. > > Cheers, > Dan ---
**Author:** ![Dan\_Everton](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dan_everton/32/1865_2.png) [@Dan\_Everton](https://discuss.elastic.co/u/Dan_Everton)\ **Post date:** [June 11, 2012, 9:55pm UTC](https://discuss.elastic.co/t/clean-shutdown-of-an-elasticsearch-node/8016/3 "2012-06-11T21:55:22Z")
On Monday, June 11, 2012 7:48:21 AM UTC+10, kimchy wrote: > The shutdown will not wait for current requests to finish. If they are > coming from other nodes in the cluster, then it will properly fail over to > other nodes, if its from a "client" directly, then a socket closed will > probably be thrown. Hrm, we're using the HTTP interface to talk to the Elasticsearch cluster and clients do get 'socket closed'. We could use the Node Client but we're rather stick to HTTP. I assume the Transport Client suffers the same problem as using HTTP or does it have built-in failover? Support for clean shutdown would be really handy. Is it something that you have on the road map? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [June 13, 2012, 6:31pm UTC](https://discuss.elastic.co/t/clean-shutdown-of-an-elasticsearch-node/8016/4 "2012-06-13T18:31:05Z")
Both the node client and transport client have automatic failover, why not build it into the HTTP client you have, should be simple to do (And you need to handle it anyhow). On Mon, Jun 11, 2012 at 11:55 PM, Dan Everton [dan@iocaine.org](mailto:dan@iocaine.org) wrote: > On Monday, June 11, 2012 7:48:21 AM UTC+10, kimchy wrote: > > > The shutdown will not wait for current requests to finish. If they are > > coming from other nodes in the cluster, then it will properly fail over to > > other nodes, if its from a "client" directly, then a socket closed will > > probably be thrown. > > Hrm, we're using the HTTP interface to talk to the Elasticsearch cluster > and clients do get 'socket closed'. We could use the Node Client but we're > rather stick to HTTP. I assume the Transport Client suffers the same > problem as using HTTP or does it have built-in failover? > > Support for clean shutdown would be really handy. Is it something that you > have on the road map? ---
**Author:** ![Dan\_Everton](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dan_everton/32/1865_2.png) [@Dan\_Everton](https://discuss.elastic.co/u/Dan_Everton)\ **Post date:** [June 13, 2012, 11:01pm UTC](https://discuss.elastic.co/t/clean-shutdown-of-an-elasticsearch-node/8016/5 "2012-06-13T23:01:00Z")
On Thursday, June 14, 2012 4:31:05 AM UTC+10, kimchy wrote: > Both the node client and transport client have automatic failover, why not > build it into the HTTP client you have, should be simple to do (And you > need to handle it anyhow). We have the Elasticsearch cluster behind a load balancer for the HTTP interface. I guess we could change the load balancer settings to do the fail over and retry. Thought it's starting to look like we'd be better off just using the Transport Client 🙂 We went with HTTP because it was fast enough and we wanted to be consistent with our choice of protocols for remote calls, i.e. HTTP and JSON all the time. What's the best practice for deploying Elasticsearch but using the HTTP interface? Or is everyone using the Node/Transport Client? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:24am UTC](https://discuss.elastic.co/t/clean-shutdown-of-an-elasticsearch-node/8016/6 "2017-07-06T03:24:19Z")