SSLSocketImpl and Handshake Notifier efficiency/thread pooling
David Schlosnagle
schlosna at gmail.com
Wed Jul 15 15:48:35 UTC 2020
Hi security-dev,
I'd like to revive this 7.5 year old thread for discussion as I have
seen seen several high throughput applications using
`SSLSocket.addHandshakeCompletedListener(HandshakeCompletedListener)`
where the "HandshakeCompletedNotify-Thread" created at
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/TransportContext.java#L640
for each TLS handshake adds significant spike in resource utilization.
For example, a service receiving say 10,000 requests per second with
handshakes required for 0.5% we're creating 50 threads per second,
which is significant thrash. We would like to avoid this thread
creation to smooth out resource utilization.
I am tracking Project Loom's progress [1] where
HandshakeCompletedListener handling may be an ideal case for virtual
thread, but would like understand if folks here are open to patches to
improve this situation in the interim? Would utilizing a cached thread
pool be an acceptable patch request option? Would providing a system
property configurable option to execute the handlers directly on the
handshaking thread be an option (e.g. when a handler is lightweight
such as incrementing handshake, cipher suite, and protocol metrics)?
Thanks,
Dave
[1] https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html
On Thu, Feb 7, 2013 at 6:27 PM Bernd Eckenfels <bernd-2013 at eckenfels.net> wrote:
>
> Hello,
>
> I have now submitted my OCA, how can we proceed here?
>
> Am 17.01.2013, 02:19 Uhr, schrieb Bernd Eckenfels
> <bernd-2013 at eckenfels.net>:
> > Am 16.01.2013, 05:04 Uhr, schrieb Xuelei Fan <xuelei.fan at oracle.com>:
> >
> >> I agree with you that create new threads in SSLSocket implementation is
> >> not good. The application is the better place to decide what's the
> >> right thread model.
> >
> >> For the same reason, using Executor in SSLSocket
> >> implementation might not be an option from my understanding.
> >
> >
> > A small change without Executor would be to have a boolean setter which
> > deactivates the Thread dispatching. The default will use new Threads, if
> > direct mode is enabled it will directly call the listeners in the data
> > thread:
> ...
>
> Greetings
> Bernd
> --
> http://bernd.eckenfels.net
More information about the security-dev
mailing list