CODEWITHSUNDEEP
playframeworkplayframework-1.x
Wildfire
Wildfire

Reputation: 6418

play framework 1.2.4 leaks https connections

I have a play framework 1.2.4 site that processes both http and https requests.

Play listens both 80 and 443 ports, there's no reverse proxy installed.

After some time, site stops responding with lots of "java.io.IOException: Too many open files" in logs.

Apparently, play sometimes leave https connections in CLOSE_WAIT state. These connections look like this:

java    24151 root  201u  IPv6             915797      0t0      TCP Ubuntu-1004-lucid-64-minimal:https->xdsl.******.net:55055 (CLOSE_WAIT)

Here is analysis of lsof dumps of alive (working for couple of hours) and dead (with 16k open files):

$ grep "CLOSE_WAIT" dead.txt | wc -l
10473
$ grep "ESTABLISHED" dead.txt | wc -l
1888
$ grep "https.*CLOSE_WAIT" dead.txt | wc -l
10473
$ grep "https.*ESTABLISHED" dead.txt | wc -l
1621

$ grep "CLOSE_WAIT" alive.txt | wc -l
7
$ grep "ESTABLISHED" alive.txt | wc -l
50
$ grep "https.*CLOSE_WAIT" alive.txt | wc -l
7
$ grep "https.*ESTABLISHED" alive.txt | wc -l
32

As you see, ~20% of requests are http, but all connections in CLOSE_WAIT state are https.

What might be causing trouble? Could it be a bug in play framework?

Upvotes: 0

Views: 743

Answers (1)

Codemwnci
Codemwnci

Reputation: 54944

On the basis of what you have described, I would concur that this does appear to be a bug in Play. It is possible that it is a problem with Netty, but as Play integrates with Netty I think the deliniation is irrelevant for your purposes. I would suggest raising a ticket on Lighthouse and possibly contacting Nicolas Leroux, who is reponsible for the https portion of the application.

However, the Play developers would be the first to say that Play is not intended to be a http and https container. The https handshaking is better performed by a fronted proxy, such as Apache. There are plenty of examples on how to do this online and on the Play documentation.

Upvotes: 2

Related Questions