RFR: SSLSocket HandshakeCompletedListeners are run on virtual threads

[Alan Bateman]

On Tue, 15 Sep 2020 19:11:12 GMT, Carter Kozak <github.com+3854321+carterkozak at openjdk.org> wrote:

>> Previously each `SSLSocket.addHandshakeCompletedListener(HandshakeCompletedListener)`
>> resulted in a new OS thread for each handshake which causes spikes in
>> resource utilization and bottlenecks in high throughput systems.
>> 
>> Virtual threads should reduce the overhead while preserving behavior to
>> the extent possible.
>> 
>> Reported to openjdk security-dev here:
>> https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022220.html
>
> However my OCA doesn't have github information. Should I submit an updated OCA with my github account info?

Thanks for identifying this potential use-case.

I found the discussion from Jan 2013 on security-dev about this issue but I was unable to find a conclusion or the
rational for why the listeners weren't called directly (which would of course would stall finishHashshake). So I think
we should re-start that discussion and get a conclusion on whether this will be changed or not. Minimally we need
javax.net.ssl.SSLSocket clarified to set expectations on the execution context and whether it runs asynchronously from
the finish (the session may be invalidated before or while the listener runs).

Assuming security-dev wants to continue to create thread per handshake notification then your patch make sense, just
need to drop inheritThreadLocals (the final parameter Thread constructor in TransportContext is false, meaning that
inheritable thread locals are not inherited in the existing code).

-------------

PR: https://git.openjdk.java.net/loom/pull/16