dotCMS not cleaning up file handles on ClientAbortException

[wezell]

If the binary servlet is serving a large file repeatedly (a video on the home page, for example) most visitors will leave the page before the file has been fully downloaded. This causes Tomcat to throw a

ClientAbortException:  java.net.SocketException: Broken pipe

after some timeout.

We need to make sure in our binary servlet to always close our file handles in a finally block to guarantee that they will be released back to the system.

To reproduce I added a Thread.sleep in the BinaryExporterServlet to simulate a big file over a network. I then hit it with ab, like this:

Benchmarking 127.0.0.1 (be patient)...apr_pollset_poll: The timeout specified has expired (70007)
cabbage:dotcms3 will$ ab -s 3 -n 10 -c 10 "http://127.0.0.1:8080/application/themes/quest/images/layout/logo-small.png?testingClientAbortException=true"
This is ApacheBench, Version 2.3 <$Revision: 1663405 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)...apr_pollset_poll: The timeout specified has expired (70007)

With each run, I could see the file handles on the OS file grow and never release:

cabbage:~ will$ lsof | grep logo-small.png | wc -l
      19
cabbage:~ will$ lsof | grep logo-small.png | wc -l
      29
cabbage:~ will$ lsof | grep logo-small.png | wc -l
      29
cabbage:~ will$ lsof | grep logo-small.png | wc -l
      49
cabbage:~ will$ lsof | grep logo-small.png | wc -l
      49
cabbage:~ will$ lsof | grep logo-small.png | wc -l
      59

[joseorsini]

I think this may be applied to the SpeedyServletAsset java class as well. We've seen Broken Pipe messages when large files are delivered in frontend pages but the stream is unexpectedly closed by client (e.g., closing the browser) (re: https://github.com/dotCMS/core/issues/7260)

[wezell]

I think the SpeedyServletAsset just calls the BinaryExporterServlet...

[joseorsini]

Got it.