Hi!
I have a Java application (that works with Novell JLDAP) as a client to OpenLDAP. This application use a connection pool in which 5 connections are open when it is started and maintain until the application is stopped. That means, the application send search, compare, update command to OpenLDAP through each of the 5 connections without closing the connections between each command that is sent to OpenLDAP.
Does OpenLDAP support application that use a connection pool ? In other words, does OpenLDAP release its memory after each command (search, ADD, ...) that is executed or it release its memory after the client application close the socket ?
I'm asking this question because memory used by OpenLDAP keep growing until it exceed the capacity of Linux.
I use RHEL v.4 with OpenLDAP v.2.2.13
Someone told me, I should not have any memory leak with this version and probably that OpenLDAP release its memory only when the socket with the client application is closed. he also said that I should not use a connection pool to send ldap command to OpenLDAP. Do you agree with that ?
thanks for your help
Sylvain
Sylvain Belleau wrote:
Hi!
I have a Java application (that works with Novell JLDAP) as a client to OpenLDAP. This application use a connection pool in which 5 connections are open when it is started and maintain until the application is stopped. That means, the application send search, compare, update command to OpenLDAP through each of the 5 connections without closing the connections between each command that is sent to OpenLDAP.
Does OpenLDAP support application that use a connection pool ? In other words, does OpenLDAP release its memory after each command (search, ADD, ...) that is executed or it release its memory after the client application close the socket ?
I'm asking this question because memory used by OpenLDAP keep growing until it exceed the capacity of Linux.
I use RHEL v.4 with OpenLDAP v.2.2.13
Someone told me, I should not have any memory leak with this version and probably that OpenLDAP release its memory only when the socket with the client application is closed. he also said that I should not use a connection pool to send ldap command to OpenLDAP. Do you agree with that ?
I think both comments from this person are incorrect:
1) 2.2.13 can have dozens of leaks and in any case is not supposed to be reliable at all. Current OpenLDAP is 2.3.38, which is few years more recent than 2.2.13
2) you can safely pool as many connections as your server can accept (in the order of thousands).
Of course, unless you upgrade to a very recent 2.3, you won't get much useful support.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
I use RHEL v.4 with OpenLDAP v.2.2.13
See the many, many, many e-mails in our lists about the thoughts RHEL and OpenLDAP RPMs. Please search our archives at:
http://www.openldap.org/lists/openldap-software/
On Thursday 11 October 2007 15:23:14 Sylvain Belleau wrote:
Hi!
I have a Java application (that works with Novell JLDAP) as a client to OpenLDAP. This application use a connection pool in which 5 connections are open when it is started and maintain until the application is stopped. That means, the application send search, compare, update command to OpenLDAP through each of the 5 connections without closing the connections between each command that is sent to OpenLDAP.
Does OpenLDAP support application that use a connection pool ? In other words, does OpenLDAP release its memory after each command (search, ADD, ...) that is executed or it release its memory after the client application close the socket ?
I'm asking this question because memory used by OpenLDAP keep growing until it exceed the capacity of Linux.
Our production RADIUS servers use connection pooling to our OpenLDAP servers, each of the 3 RADIUS servers using 8 persistent connections (to 4 load-balanced LDAP servers, thus an average of 6 connections to each slave just for RADIUS). We don't see this behaviour. We are running 2.3.x (at present 2.3.34, have some work to do regarding other features I need before I upgrade them to 2.3.38) on RHEL4 ES x86_64.
You may be interested in these: http://staff.telkomsa.net/packages/rhel4/openldap/
Regards, Buchan
openldap-software@openldap.org