Re: RFR: SSLSocket HandshakeCompletedListeners are run on virtual threads

[Carter Kozak]

On Wed, Sep 16, 2020, at 10:11, Alan Bateman wrote:
> On 16/09/2020 14:30, Carter Kozak wrote:
> >
> > I completely agree that running listeners on the completion thread would be ideal and allow the most flexibility for
> > consumers, but I'm worried that changing the behavior between java releases without a new API (perhaps an overload
> > which additionally takes an Executor instance) would cause too much friction for existing consumers. Listeners which
> > expect to execute long running operations would potentially cause performance regressions when taking a java release
> > including the change, which I'd imagine would make it a non-starter. Loom virtual threads provide the ability to
> > preserve existing behavior without the overhead incurred by OS threads. I'd be happy to start a thread to discuss a
> > mechanism to listen for handshake completion without dispatching to additional threads (virtual or otherwise), but I
> > think that would be a separate, parallel, change. What do you think?
> >
> Yes, it would be good to restart the discussion and also re-verify that 
> the API is actually useful, esp. with the potential for the session to 
> be stale when listener is notified. If the interesting cases are 
> monitoring or logging then maybe there are alternatives to explore.
> 
> -Alan
> 

I've started a security-dev discussion here: https://mail.openjdk.java.net/pipermail/security-dev/2020-September/022482.html

-Carter Kozak