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 system’s 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) without 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://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10

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"?>


<httpConnections>


<mode>persistent</mode>


</httpConnections>

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"?>


<httpConnections>


<mode>non-persistent</mode>


</httpConnections>

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