Gracefully and quickly evict HTTP persistent connections

Title of this article might sound like an oxymoron. How can persistent HTTP connections be gracefully and at the same time quickly evicted? By Gracefully I mean here the client applications to close the connections by themselves without jeopardizing the transaction. Before answering this question, let’s see why we even want to do it.

Persistent Connections are meant to reduce the systems resource usage and response time of the transaction. But it comes with a price – whenever server needs to be taken out of rotation gracefully, operations team has to wait for a prolonged period of time (often times few hours) until all the persistent connections gets drained out. It would significantly increase the applications deployment time. Especially for the applications which are deployed across multiple servers.

Here is a solution we built, where operations team can take out the server quickly in matter of minutes (if not in seconds) with out affecting client transactions.

HTTP Header – Connection: close

According HTTP specification whenever Server wants to close its connection, it would set the HTTP header element “Connection:Close”. It’s a notification to the HTTP Client to close the connection on their end.

For non-persistent connections, server would set “Connection:Close” HTTP header element on each and every response. So that for subsequent transaction client would open a new connection.

So we engineered a solution such that by default server would support persistent connection i.e. it wouldn’t send “Connection:Close” element in the HTTP Header, but when Server needs to be taken out of rotation, automatically from that moment it switch to non-persistent connection mode i.e. it would start to insert “Connection:Close” HTTP Header for each response. In this way all the open connections in the server would get drained down quickly in matter of few minutes (if not in seconds).

Further details on this HTTP Header element refer to

HTTP Clients

In order to confirm whether commonly used HTTP Clients respect the “Connection:Close” we carried out  an experiment to see whether connections get closed when “Connection:Close” header element is set, This Experiment was conducted on following HTTP Clients:

  • Mozilla FireFox
  • Internet Explorer
  • Chrome
  • JAVA SDK (HTTPURLConnection)
  • Apache Commons HTTP Client
  • HTTP Components HTTP Client Module

All of these clients respect the “Connection:Close” element.

Still there could be clients who may not respect this HTTP Header element, but they should be very minimal in number.

Servlet Filter Implementation

In order to implement the above solution in JEE enabled application server, we introduced a Global ServletFilter which would insert the HTTP Header element “Connection:Close”  on the HTTP responses, only operations team decide to take that server out of rotation.

A new XML configuration file was introduced etc/http-connection.xml within the web application, which would look like:

<?xml version=”1.0″ encoding=”UTF-8″?>




When Operations team decides to take the server out of rotation, they would change the mode to “non-persistent” i.e.

<?xml version=”1.0″ encoding=”UTF-8″?>




Once they make this switch ServletFilter will start to insert “Connection:Close” header element, which would then start to drain down all the connections.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: