[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Intermittent hang/deadlock when iterating through LDAP search results using JLDAP
Hi Marc,
Yes, there is a pool implementation but when I had tried it out about 8
months ago, it had resulted in a hang as well, but on a different API. I do
vaguely remember that the hang occured after retrieving a couple of
connections, even though I was releasing the ones I didn't need. I debugged
adn verified that connection objects were being released at that time. The
hang would occur randomly - sometime when trying to acquire the 24th
connection, sometimes less, sometimes more. I don't have the code handy
either, but I know it was because of these issues that I had switched to
using the clone() approach, which seemed to work a lot better since I wasn't
really pooling any connections and they have always been readily available -
I would just create a clone whenever I needed it and close it when done,
while the master connection would always remain open.
Since nobody knows of a solution to the hang problem using clones, I'm
considering creating a fresh connection object for each thread that accesses
the OpenLDAP server via JLDAP. For each object I'm planning on connecting to
the server and then doing a bind before anything else. I was wondering how
performant that approach might be - wud it be a lot slower, or consume more
resources than using the clone() approach where no connect/bind was
required?
If it is much slower, does anyone have a workaround - such as perhaps making
certain types of accesses to the cloned connections (like iterating through
search results) explicitly thread-safe by locking some shared object before
iteration ...? The reason I say this is because it seems that the
"MessageQueue" is where all threads get blocked indicating that perhaps it
is being inappropriately shared across all clones perhaps allowing certain
race conditions to go unchecked, and then ending in a deadlocked state...
Thanks for the help!
Best regards,
Safdar
On 9/9/05, Marc Boorshtein <mboorshtein@gmail.com> wrote:
>
> Yes, both JLDAP and OpenLDAP are supprted on the list, I just wanted to
> see if the issue was with just one server or many. Instead of cloning the
> master, I believe there is a pool implementation that comes with JLDAP in
> com.novell.ldap.connectionpool. Is this in a multithreaded environment?
>
> Marc
>
> On 9/8/05, Safdar Kureishy <safdar.kureishy@gmail.com> 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).
> >
> > Thanks,
> > Safdar
> >
> > On 9/8/05, Safdar Kureishy < safdar.kureishy@gmail.com> wrote:
> > >
> > > Hi Marc,
> > >
> > > I've only seen this happen with OpenLDAP so far. I am also accessing
> > > Active Directory using JLDAP (for different information) but I hven't seen
> > > this problem occur there.
> > >
> > > I posted to this newsgroup since JLDAP is supposed to come under its
> > > domain ...
> > >
> > > Have you seen this problem as well?
> > >
> > > Thanks,
> > > Safdar
> > >
> > > On 9/8/05, Marc Boorshtein < mboorshtein@gmail.com> wrote:
> > > >
> > > > Does this happen with any other ldap server?
> > > >
> > > > Marc
> > > >
> > > > On 9/8/05, Safdar Kureishy < safdar.kureishy@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm using JLDAP to access an OpenLDAP server and query for
> > > > > information.
> > > > > There are situations (intermittent) where search result iteration
> > > > > returned
> > > > > via
> > > > > LDAPConnection::search() (synchronous search) ends up in a
> > > > > deadlock/hang of
> > > > > some sort.
> > > > >
> > > > > Here are some strack traces:
> > > > > Thread [http-8453-Processor2] (Suspended)
> > > > > Object.wait(long) line: not available [native method]
> > > > > MessageVector(Object).wait() line: 429 [local variables
> > > > > unavailable]
> > > > > MessageAgent.getLDAPMessage(Integer) line: not available
> > > > > LDAPSearchQueue(LDAPMessageQue ue).getResponse(Integer) line: not
> > > > > available
> > > > > LDAPSearchQueue(LDAPMessageQueue).getResponse() line: not
> > > > > available
> > > > > LDAPSearchResults.getBatchOfResults () line: not available
> > > > > LDAPSearchResults.resetVectors() line: not available
> > > > > LDAPSearchResults.hasMore() line: not available [local variables
> > > > > unavailable]
> > > > >
> > > > > I also see a stack dump alongside this that might be related to it
> > > > > at
> > > > > the network level:
> > > > >
> > > > > Thread [http-8454-Processor4] (Suspended)
> > > > > PlainSocketImpl.socketAccept(SocketImpl) line: not available
> > > > > [native method]
> > > > > PlainSocketImpl.accept(SocketImpl) line: 353
> > > > > SSLServerSocketImpl(ServerSocket).implAccept(Socket) line: 448
> > > > > SSLServerSocketImpl.accept() line: not available
> > > > > JSSE14SocketFactory(JSSESocketFactory).acceptSocket(ServerSocket)
> > > > > line: 110
> > > > > PoolTcpEndpoint.acceptSocket() line: 368
> > > > > TcpWorkerThread.runIt(Object[]) line: 549
> > > > > ThreadPool$ControlRunnable.run() line: 683
> > > > > ThreadWithAttributes(Thread).run() line: 534
> > > > >
> > > > > Another similar stack trace is:
> > > > > Thread [http-8444-Processor15] (Suspended)
> > > > > Object.wait(long) line: not available [native method] [local
> > > > > variables
> > > > > unavailable]
> > > > > MessageVector(Object).wait() line: 429
> > > > > MessageAgent.getLDAPMessage(Integer) line: not available
> > > > > LDAPSearchQueue(LDAPMessageQueue).getResponse(Integer) line: not
> > > > > available
> > > > > LDAPSearchQueue(LDAPMessageQueue).getResponse() line: not
> > > > > available
> > > > > LDAPSearchResults.getBatchOfResults() line: not available
> > > > > LDAPSearchResults.resetVectors() line: not available
> > > > > LDAPSearchResults.hasMore() line: not available
> > > > > OpenLDAPQueryImpl.execute() line: 153
> > > > >
> > > > > Is anyone familiar with the solution/workaround to this problem?
> > > > > I'm not
> > > > > using
> > > > > SSL for now, but I plan to eventually switch to using SSL as well.
> > > > >
> > > > > Here is the code I'm using to invoke the search (it's a pretty
> > > > > simple
> > > > > search). I obtain a connection instance by cloning a "master"
> > > > > connection. After I've iterated through all the results, I close
> > > > > the
> > > > > cloned connection. According to the Javadoc for this, the call to
> > > > > close() on the cloned connection should not affect the master
> > > > > connection in any way.
> > > > >
> > > > > // Here I initialize the master connection:
> > > > > ...
> > > > > this.masterConnection.connect(host, port);
> > > > > this.masterConnection.bind(LDAPConnection.LDAP_V3,
> > > > > this.loginDN, passwd);
> > > > > ...
> > > > >
> > > > > // Here I search by cloning the master connection:
> > > > > ...
> > > > > ...
> > > > > LDAPConnection connection = this.masterConnection.clone();
> > > > > LDAPSearchResults results = connection.search(this.baseDN,
> > > > > ldapScope, searchStr, requestedAttributes, false);
> > > > > try {
> > > > > while (results.hasMore ()) { <<<<<< THIS IS WHERE THE
> > > > > HANG/DEADLOCK OCCURS
> > > > > LDAPEntry nativeEntry = results.next();
> > > > > LDAPAttribute idAttr =
> > > > > nativeEntry.getAttribute(this.staticIdAttribute);
> > > > > ...
> > > > > ...
> > > > > } finally {
> > > > > // Always release the connection:
> > > > > this.adapter.getConnectionPoolManager
> > > > > ().releaseConnection(connection);
> > > > > }
> > > > >
> > > > > Any help will be greatly appreciated.
> > > > >
> > > > > Thanks,
> > > > > Safdar
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>