I'm not sure if it really worthy of new APIs. Old applications cannot
benefit from new APIs. Let's see if the Loom project could meet the
performance requirements firstly.
Xuelei
On 9/18/2020 11:09 AM, Carter Kozak wrote:
Thanks Xuelei,
As someone who primarily produces libraries consumed
: Xuelei Fan ; Bradford Wetmore
; security-dev@openjdk.java.net
Betreff: Re: SSLSocket HandshakeCompletionListener Threading
Thanks Xuelei,
As someone who primarily produces libraries consumed across many projects I
would prefer not to use global jvm state. I worry that a global property
Thanks Xuelei,
As someone who primarily produces libraries consumed across many projects I
would prefer not to use global jvm state. I worry that a global property
requires administrators to have knowledge of every HandshakeCompletedListener
that is used, and library authors have limited abilit
I thought more about the problem. I could see the performance
improvement requirements for heavy loaded system. But it may not worthy
of a complicated proposal, as the Loom feature could mitigate the impact.
Maybe, a new system property could be defined, for example,
"jdk.tls.server/client.h
From a coding point of view, if Xuelei doesn't have a further
suggestion, using virtual threads like you have suggested seems to be a
good solution. I'm ok with this change for Project Loom. Loom has a
lot of promise for things like this.
I've never been thrilled with the threading of the
H
Good catch!
Alternatively, I was wondering if it is possible to delegate the job to
listeners, without modify the APIs, for example by implementing a
Runnable interface (not a proposal, just a guess for now). I don't like
the creation of threads in the JSSE provider, as application could take
