[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Intermittent hang/deadlock when iterating through LDAP search results using JLDAP
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,
Safdar
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.
>
> Marc
>
> 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
> > 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 <http://www.mentata.com>
> >
> > ... forthwith donning my flame-retardant assflaps
> >
>
>