[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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

... forthwith donning my flame-retardant assflaps