Connection Reset exception com.day.ldap.LDAPConnThread | Community
Skip to main content
samthadhani2
Level 2
October 16, 2015
Solved

Connection Reset exception com.day.ldap.LDAPConnThread

  • October 16, 2015
  • 3 replies
  • 1639 views

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)

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Ben_Peter

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
 

3 replies

Ben_Peter
October 16, 2015

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
Level 2
October 16, 2015

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
Ben_PeterAccepted solution
October 16, 2015

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