Nice fix! Thanks, Xuelei
On 6/29/2016 9:18 AM, Jamil Nimeh wrote: > 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
