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-2...@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-2...@eckenfels.net>: > > Am 16.01.2013, 05:04 Uhr, schrieb Xuelei Fan <xuelei....@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
