Glassfish 30 second delay when connecting to LDAP via SSL - ssl

Question

I'm trying to connect to my company's LDAP via SSL using GlassFish. Everything works as expected, except that sometimes connecting takes a very long time.
After enabling the ssl debugging, I found that there is sometimes, but not always, a 30 second delay in the Change Cipher Spec. An example of the delay is shown below.
[2020-06-18T09:11:51.806+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=32 _ThreadName=Thread-8] [timeMillis: 1592467911806] [levelValue: 800] [[
http-listener-1(1), WRITE: TLSv1.2 Handshake, length = 40]]
[2020-06-18T09:12:22.030+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=32 _ThreadName=Thread-8] [timeMillis: 1592467942030] [levelValue: 800] [[
http-listener-1(1), READ: TLSv1.2 Change Cipher Spec, length = 1]]
[2020-06-18T09:12:22.030+0100] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=32 _ThreadName=Thread-8] [timeMillis: 1592467942030] [levelValue: 800] [[
http-listener-1(1), READ: TLSv1.2 Handshake, length = 40]]
Here is the code used to connect to the LDAP
final Hashtable<String, String> env = new Hashtable<String, String> ();
final String url = "ldaps://" + ldapHostAddress + ":" + ldapPort;
env.put (Context.SECURITY_PROTOCOL, "ssl");
env.put (Context.PROVIDER_URL, url);
env.put (Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put (Context.SECURITY_AUTHENTICATION, "simple");
env.put (Context.SECURITY_PRINCIPAL, principalDN);
env.put (Context.SECURITY_CREDENTIALS, principalPassword);
// Ensure the objectGUID is handled as a binary object, rather than a string.
env.put ("java.naming.ldap.attributes.binary", "objectGUID");
LdapContext connection = new InitialLdapContext (env, null);
Running this code from the command line does not appear to suffer from the 30 delay, so I can only assume it's an issue with GlassFish. Any suggestions would be appreciated.

Answer 1

Turns out that GlassFish was occasionally having problems resolving the DNS name of the LDAP server. Replacing the DNS name with the IP address removed the delay when performing the handshake.