Hi Emmanuel, (My proposition about filling a bug report was in response to Kirian :))
I agree that if I open a connection I'm responsible to close it. So I've tried another implementation that you can find attached with a pool and a release operation when a new SearchFuture is initiated. And badly I encountered the same issue Regards, Sebastien BAHLOUL IAM / Security specialist Ldap Synchronization Connector : http://lsc-project.org Blog : http://sbahloul.wordpress.com/ 2014-11-28 9:41 GMT+01:00 Emmanuel Lécharny <[email protected]>: > Le 28/11/14 08:46, Sébastien Bahloul a écrit : > > 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 ? > > Why do you think this is a LDAP API bug ? When you pull a new connection > *you* are responsible for closing it. If you don't close it, and create > new ones everytime you need a connection, they will obviously accumulate. > > Be sure that you always close the connections. > > Otherwise, I do think that polling is not the right way to deal with > updates done on the server. You use an async connection, that means > yo'ull get a Future that can be used to know when some update occurs : > you just have to spawn a thread that wait on this future (you can even > wit for a period of time, and loop). This is way better than retrying > when you get nothing. > > > Again, check the traces, you can see than more than 900 connections get > created and are waiting, that means you *created* them. You create, you > close... >
