Connection Reset exception com.day.ldap.LDAPConnThread

[samthadhani2]

Hi,

We have been testing our ldap processes with 3500 concurrent users and there seems to be some connection reset exceptions which have been thrown by day processes. This does not happen under normal 50-100 users load. 

Can somebody please guide me if i can better manage it or do i need to raise a daycare for it? The library(com.day.ldap.LDAPConnThread) makes direction connection with ldap server and none of our processes our involved with any interaction.

02.10.2014 05:02:45.326 ERROR [LDAPConnThread 192.168.143.21:636] com.day.ldap.LDAPConnThread network error on LDAP connection java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at com.day.ldap.ber.stream.BERElement.getElement(BERElement.java:101)
at com.day.ldap.LDAPConnThread.run(LDAPConnThread.java:443)
02.10.2014 05:02:45.326 ERROR [LDAPConnThread 192.168.143.21:636] com.day.ldap.LDAPConnThread network error on LDAP connection java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at com.day.ldap.ber.stream.BERElement.getElement(BERElement.java:101)
at com.day.ldap.LDAPConnThread.run(LDAPConnThread.java:443)
02.10.2014 05:02:45.328 ERROR [LDAPConnThread 192.168.143.21:636] com.day.ldap.LDAPConnThread network error on LDAP connection java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at com.day.ldap.ber.stream.BERElement.getElement(BERElement.java:101)
at com.day.ldap.LDAPConnThread.run(LDAPConnThread.java:443)

[Ben_Peter]

Sam,

have you checked on the LDAP server side?

This looks very much as if your LDAP server is not capable of handling the load.

Cheers,
Ben
 

[samthadhani2]

Ben_Peter wrote...

Sam,

have you checked on the LDAP server side?

This looks very much as if your LDAP server is not capable of handling the load.

Cheers,
Ben
 

Hi Ben,

Thanks for your comments. I think i found a clue not sure if it is gonna work. Our ldap_login.conf file has this setting 

cache.expiration="600"
cache.maxsize="100";

I think it it too low for system in which so many users would exist. The reason from this hypothesis is because a lot of request with Active Directory are for Credential Validation which Day library does and we don't as it might be happening often. Do you know of any recommended values for a system with million users?

Thanks.

[Ben_Peter · Accepted solution]

Hi Sam,

the number of users as such is playing together with the frequency of logins performed.
With millions of users (to these all log in through LDAP?), a cache size of 100 obviously is no cache at all.
I'd start with trying to get an understanding of how many of these users log in and how often, then adjust expiration and cache size accordingly on a test system and run performance tests, keeping a close eye on heap space.

Cheers,
Ben