Re: Intermittent hang/deadlock when iterating through LDAP search results using JLDAP

[Jon Roberts <jon@jonanddeb.net>]

Safdar Kureishy wrote:
> Just so you know, I'm using different threads to run queries using cloned 
> connections from the same "master" connection...
>
> So when this problem occurs, all those threads seem to pile up one on top of 
> the other and remain blocked on the same call (as shown in the call stack).

I have recently experienced failures resulting from blocked connections, 
too. I use the com.novell.ldap.connectionpool.PoolManager, which does 
something similar to your cloned connection approach. My assumption up 
to this point has been that it is related to ITS #3327 and/or ITS #3357, 
but I am currently rebuilding my development environment and can't yet 
easily test the patch submitted with #3357. I should be doing so in the 
coming weeks, and I'll share the results.

I would like to take this opportunity to point out that the above-cited 
issues were reported over a year ago and have languished in ITS with 
OPEN status since then. I also wish to add that my own batting average 
is pretty low: I have submitted 3 JLDAP patches, each with unencouraging 
outcomes. The first (#3102) was inexplicably misapplied, leading to 
#3202 (fixed in CVS by June 2004 but only recently closed in ITS). The 
second (#3728) has been unregarded since its submission last May. 
Finally there's my most recent attempt to contribute (#3911), which is 
critical to enabling JLDAP to be compiled under Java v1.5 (it currently 
fails). This issue was successfully submitted Aug 1 and has now 
COMPLETELY DISAPPEARED FROM ITS! Thanks.

It's not as if JLDAP has been inert; all sorts of arbitrary functions 
have been added by those with direct access to the code base in the 
meantime. I now see inconsistent naming/organizing (e.g. DsmlConnection 
vs. DSMLSearchResults vs. util.DSMLWriter). I get whole new dependencies 
every time I compile, which is why I now use my own Ant files to ignore 
dozens of classes when I build JLDAP. But hey, now I can use SPML just 
like LDAP (?), so who should care if the codebase might be broken, 
uncompilable, bloated, or ethnocentric, right?

I have a great deal of respect for the OpenLDAP project and I have had 
many pleasant experiences with the Java LDAP APIs thus far to balance 
these criticisms. However, I do take issue with the recent JLDAP 
development direction. In short, I would prefer to see something that 
does the fundamentals effectively, cleanly, and flexibly vs. a sloppy 
repository for code that is all things to a few people.

Jon Roberts
www.mentata.com

... forthwith donning my flame-retardant assflaps