Hi all,
This fixes a couple problems. The first is a file descriptor leak in
the SSLSocketWithStapling test. The second is a thread exhaustion issue
that can happen when many many (> 1000) SSLContext objects are created
with StatusResponseManagers. I think this is a pretty far flung edge
case in the real world, but our test framework manages to hit it from
time to time. By allowing the core threads in the StatusResponseManager
to time out, it prevents the system from running out of threads when so
many SSLContext objects are created and used to support servers that
have stapling enabled (all of that has to be true to run into this
issue). I was able to create over 100K SSLContext objects in rapid
succession without running into any kind of thread exhaustion with this fix.
I also added a discard policy for another rare case (one I haven't seen
happen) where the thread pool could be completely busy and another job
needs to be serviced. Rather than the default policy which throws an
exception, it is better to discard the job so the connection can
proceed, even if the result might be that stapling is disabled for that
connection. Again, an exceedingly rare edge case, one never seen even
in performance tests.
Bug: https://bugs.openjdk.java.net/browse/JDK-8143302
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8143302/webrev.01/
Thanks,
--Jamil
