[jboss-jira] [JBoss JIRA] (WFCORE-997) Security realm using ldaps hangs forever during SSL handshake, when ldap server is killed

Darran Lofthouse (JIRA) issues at jboss.org
Wed Oct 7 11:08:00 EDT 2015


     [ https://issues.jboss.org/browse/WFCORE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-997:
------------------------------------
    Attachment: DeadListener.java


The attached file starts a ServerSocket that reproduces this - i.e. it accepts the connection but never does anything with it so the server ends up stuck in the following call: -

{noformat}
"Remoting "eyrie:MANAGEMENT" task-1" #120 prio=5 os_prio=0 tid=0x00007efbb0004800 nid=0x5323 waiting for monitor entry [0x00007efc58f3b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1350)
	- waiting to lock <0x00000000f56e0450> (a java.lang.Object)
	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
	- locked <0x00000000f56ff778> (a sun.security.ssl.AppOutputStream)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
	- locked <0x00000000f570c518> (a java.io.BufferedOutputStream)
	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426)
	- locked <0x00000000f56deb28> (a com.sun.jndi.ldap.Connection)
	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)
	at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
	- locked <0x00000000f56de9d8> (a com.sun.jndi.ldap.LdapClient)
	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:192)
	- locked <0x00000000f56de9d8> (a com.sun.jndi.ldap.LdapClient)
	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788)
	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
	at javax.naming.InitialContext.init(InitialContext.java:244)
	at javax.naming.InitialContext.<init>(InitialContext.java:216)
	at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
	at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:263)
{noformat}

> Security realm using ldaps hangs forever during SSL handshake, when ldap server is killed
> -----------------------------------------------------------------------------------------
>
>                 Key: WFCORE-997
>                 URL: https://issues.jboss.org/browse/WFCORE-997
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 2.0.0.CR3
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR7
>
>         Attachments: DeadListener.java, SecurityRealmLDAPSHandshakeHangs.pcap, StackTraceConnectTimeoutInLDAPSConnection.txt, StackTraceFromThreadDump.txt
>
>
> During failover testing we hit the problem of stuck thread. When ldap server is killed in particular time of ssl handshake EAP hangs and waits forever on response, which will never come. Causing thread to block forever. Same problem can be seen in LdapLoginModule using ldaps without specifying com.sun.jndi.ldap.connect.timeout value.
> Possible solution is to add option to declare com.sun.jndi.ldap.connect.timeout for security realm and provide some default non-empty value, e.g. 15 seconds.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


More information about the jboss-jira mailing list