directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Threads issue
Date Fri, 28 Nov 2014 08:41:12 GMT
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

View raw message