If it's the same issue as #957, you can configured the persistent_timeout now. Please try that and if it doesn't work, reopen this issue.

Thanks @evanphx, but adjusting timeouts doesn't affect this. This error occurs without going through the ELB.

Hm, ok. I wonder if perhaps on a worker exit persistent sockets aren't being closed. That's not an issue for normal HTTP sockets because the process exit will close the socket, but would be an issue for SSL sockets because the close actually sends data back across telling the other side that it's closed. I'll investigate.

Nope, close is called on all sockets. Oh, are you using actioncable or websockets or something else that perhaps uses hijack? If so, I'm betting they're not closing the sockets down on shutdown...

I've reproduced the error with just a puma config file (no rack app) here: https://github.com/mattyb/puma-socket-test

Thanks so much for the reproduction! I'm working on it now.

@mattyb That should fix your problem. Do you have a way to try it out easily before I release the fix?

Thanks for working on this! I no longer see the SSL errors popping up in the console and there are new messages in the verbose logs about connections being closed. Unfortunately, even with the reproduction code updated to the 46416cb commit, I still see failed requests from ab.

Concurrency Level:      25
Time taken for tests:   21.217 seconds
Complete requests:      3000
Failed requests:        21
   (Connect: 0, Receive: 0, Length: 21, Exceptions: 0)

It's possible that this is a problem with ab's implementation, though I believe I'm using the latest version. I confirmed that there are no errors if I bind tcp without ssl. I assume the fact that all the errors are failures in "Length" is relevant.

I could try the new commit on our real app in our staging environment and see if the ELB handles whatever error is happening more cleanly, but it seems like something may still be awry in puma.