Hi Kiran Emmanuel, Thank you for your response. I'll just provide a piece of context about how LSC is handling asynchronous search : LSC is calling the SyncReplSourceService getNextId() method in a periodical basis. If an existing persistent search (in fact with the LDAP Content Synchronisation control activated when using OpenLDAP) materialized by the SearchFuture object has already bean fired, it checks if an entry is available. If so it retrieves and handles it. If not LSC will wait for a few seconds and will retry. If no persistent search is already there (test sf == null or sf.isCanceled()), then it fires a new search on a new connection (assuming that the search has been ended because of a connection timeout). I understand that it is not the right way to do it and/or do you prefer that i fill a but report ?
Kind regards, Sebastien BAHLOUL IAM / Security specialist Ldap Synchronization Connector : http://lsc-project.org Blog : http://sbahloul.wordpress.com/ 2014-11-28 8:08 GMT+01:00 Emmanuel Lécharny <[email protected]>: > Le 28/11/14 00:06, Sébastien Bahloul a écrit : > > To Apache LDAP API guys, > > > > http://pastebin.fr/37581 > > > > > FTR, there are 893 opened connections in the trace you sent. No wonder > why you have memory issues at some point when you open that many > connections without closing them. > > Close them. All of them. If your pool is not doing the job correctly, > fix the pool. >
