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

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


Two Things:

1.  I've not used the LDAP connection pool myself, so I don't know how stable it is.  I've used the jakarta commons logging code with a lot of success.  It's a pretty straight forword implementation process.

2.  The code is in the openldap CVS repository.


On 9/9/05, Safdar Kureishy <safdar.kureishy@gmail.com> wrote:
The Novell website doesn't give out the source code for JLDAP. I was thinking perhaps I could debug the problem myself and see if I can find the root cause. Would anyone be able to point me to the source code for JLDAP? And if I wanted to submit patches where I could do so?

Thanks in advance,

On 9/9/05, Marc Boorshtein < mboorshtein@gmail.com> wrote:
Just a quick note on some of the things you've brought up:

1.  Yes, the batting average on JLDAP (and JDBC-LDAP) has not been good.  I've tried my best to keep up, but have not been getting any support from novell. 

2.  The dependencies issue was fixed.  If you do not have the appropriate libraries to support DSMLConnection or SPMLConnection then those classes are skipped durring the compile. 


On 9/9/05, Jon Roberts < jon@jonanddeb.net> wrote:
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

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