-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
8, 9, 10, 11
-
x86_64
-
linux
ADDITIONAL SYSTEM INFORMATION :
Linux mailarchiva-usa-h 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
All methods in Provider.getService() are synchronized. This causes significant contention. On systems that are performing a large number of TLS connections, Provider.getService() can take up to 32 seconds to complete.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This issue happens in systems with large amount of TLS connections. See: https://i.stack.imgur.com/KVM79.jpg for a demo of the same.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
We do not expect to see contention in the Provider.getService class.
ACTUAL -
You can see that monitors are blocked for a long period of time.
Java Monitor Blocked
at java.security.Provider.getService(String, String)
at sun.security.jca.ProviderList$ServiceList.tryGet(int)
at sun.security.jca.ProviderList$ServiceList.access$200(ProviderList$ServiceList, int)
at sun.security.jca.ProviderList$ServiceList$1.hasNext()
at javax.crypto.KeyGenerator.nextSpi(KeyGeneratorSpi, boolean)
at javax.crypto.KeyGenerator.<init>(String)
at javax.crypto.KeyGenerator.getInstance(String)
at sun.security.ssl.JsseJce.getKeyGenerator(String)
at sun.security.ssl.HandshakeMessage$Finished.getFinished(HandshakeHash, int, SecretKey)
at sun.security.ssl.HandshakeMessage$Finished.<init>(ProtocolVersion, HandshakeHash, int, SecretKey, CipherSuite)
at sun.security.ssl.ServerHandshaker.sendChangeCipherAndFinish(boolean)
at sun.security.ssl.ServerHandshaker.clientHello(HandshakeMessage$ClientHello)
at sun.security.ssl.ServerHandshaker.processMessage(byte, int)
at sun.security.ssl.Handshaker.processLoop()
at sun.security.ssl.Handshaker.process_record(InputRecord, boolean)
at sun.security.ssl.SSLSocketImpl.readRecord(InputRecord, boolean)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake()
at sun.security.ssl.SSLSocketImpl.startHandshake(boolean)
at sun.security.ssl.SSLSocketImpl.startHandshake()
at org.subethamail.smtp.command.StartTLSCommand.execute(String, Session)
at org.subethamail.smtp.server.CommandHandler.handleCommand(Session, String)
at org.subethamail.smtp.server.Session.runCommandLoop()
at org.subethamail.smtp.server.Session.run()
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
at java.util.concurrent.ThreadPoolExecutor$Worker.run()
at java.lang.Thread.run()
CUSTOMER SUBMITTED WORKAROUND :
There is no workaround. This is a critical performance issue in the Java libraries. The Java Provider class needs to be refactored with modern concurrent programming principles. Several bugs have been raised in the past regarding this issue, and each time it gets ignored by Oracle.
FREQUENCY : always
Linux mailarchiva-usa-h 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
All methods in Provider.getService() are synchronized. This causes significant contention. On systems that are performing a large number of TLS connections, Provider.getService() can take up to 32 seconds to complete.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This issue happens in systems with large amount of TLS connections. See: https://i.stack.imgur.com/KVM79.jpg for a demo of the same.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
We do not expect to see contention in the Provider.getService class.
ACTUAL -
You can see that monitors are blocked for a long period of time.
Java Monitor Blocked
at java.security.Provider.getService(String, String)
at sun.security.jca.ProviderList$ServiceList.tryGet(int)
at sun.security.jca.ProviderList$ServiceList.access$200(ProviderList$ServiceList, int)
at sun.security.jca.ProviderList$ServiceList$1.hasNext()
at javax.crypto.KeyGenerator.nextSpi(KeyGeneratorSpi, boolean)
at javax.crypto.KeyGenerator.<init>(String)
at javax.crypto.KeyGenerator.getInstance(String)
at sun.security.ssl.JsseJce.getKeyGenerator(String)
at sun.security.ssl.HandshakeMessage$Finished.getFinished(HandshakeHash, int, SecretKey)
at sun.security.ssl.HandshakeMessage$Finished.<init>(ProtocolVersion, HandshakeHash, int, SecretKey, CipherSuite)
at sun.security.ssl.ServerHandshaker.sendChangeCipherAndFinish(boolean)
at sun.security.ssl.ServerHandshaker.clientHello(HandshakeMessage$ClientHello)
at sun.security.ssl.ServerHandshaker.processMessage(byte, int)
at sun.security.ssl.Handshaker.processLoop()
at sun.security.ssl.Handshaker.process_record(InputRecord, boolean)
at sun.security.ssl.SSLSocketImpl.readRecord(InputRecord, boolean)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake()
at sun.security.ssl.SSLSocketImpl.startHandshake(boolean)
at sun.security.ssl.SSLSocketImpl.startHandshake()
at org.subethamail.smtp.command.StartTLSCommand.execute(String, Session)
at org.subethamail.smtp.server.CommandHandler.handleCommand(Session, String)
at org.subethamail.smtp.server.Session.runCommandLoop()
at org.subethamail.smtp.server.Session.run()
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
at java.util.concurrent.ThreadPoolExecutor$Worker.run()
at java.lang.Thread.run()
CUSTOMER SUBMITTED WORKAROUND :
There is no workaround. This is a critical performance issue in the Java libraries. The Java Provider class needs to be refactored with modern concurrent programming principles. Several bugs have been raised in the past regarding this issue, and each time it gets ignored by Oracle.
FREQUENCY : always
- duplicates
-
JDK-8206334 With heavy load of SSL handshakes, the application gets stuck on java.security.Provider.getService(String, String)
- Closed
-
JDK-7092821 java.security.Provider.getService() is synchronized and became scalability bottleneck
- Resolved
- relates to
-
JDK-8289642 crash with Problematic frame: # j sun.security.jca.ProviderList$ServiceList.tryGet(I)Ljava/security/Provider$Service;+112
- Closed