directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Henne (JIRA) <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-586) Reliable hang of DS during query
Date Thu, 29 Jun 2006 23:27:31 GMT
    [ http://issues.apache.org/jira/browse/DIRSERVER-586?page=comments#action_12418534 ] 

Jörg Henne commented on DIRSERVER-586:
--------------------------------------

Sorry for the long delay, unfortunately I was busy with other projects.

In order to investigate this problem a but further, I wrote a simple test case which can still
(RC3!) be used to trigger hangs and errors in various ways. 

First of all, a few words on the test case:
- In order to run it, you need a running DS (obviously) and an existing path in the directory
somewhere which can stand some abuse. 
- You can configure all that in the getEnv() method.
- The test case will remove everything below the specified path!

There are three tests in the test case:
- testSingleThreaded() runs 100 cycles of [create 10 OUs; remove them]. For every operation
a separate InitialDirContext is used. However, connection pooling is turned on in getEnv().
This test usually runs just fine.

- testSingleThreadedKeepLingeringCtx() exploits a bug I made some time ago: createSubcontext()
returns a subcontext which must be closed explicitely. I you don't, the SUN LDAP provider
will open a large-ish number of connections (depending on when the garbage collection runs).
This test hangs pretty reliably starting at around 10 open connections.

- testMultiThreaded()  is yet another variation of the theme, this time creating/deleting
stuff in a multi-threaded fashion. Even with proper Context management this hangs very reliably,
too.

Bottom line: with respect to the subject of the bug I'd say that my initial assumption that
there is a problem with queries was wrong. Once something triggered the hang, every connection
attempt within a few seconds hangs, too. Query or not. The second test is based on a clearly
broken connection management, but DS should still behave properly. The third test demonstrates
the hang with a proper (IMHO) connection management, but in a perfectly legal multi-threading
situation.

This is how the multi-threading hang looks like:

Client-side threads:
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner at localhost:4923
	System Thread [Finalizer] (Running)
	System Thread [Reference Handler] (Running)
	Thread [main] (Running)
	System Thread [Signal Dispatcher] (Running)
	Thread [ReaderThread] (Running)
	Thread [Thread-0] (Running)
	Thread [Thread-1] (Running)
	Thread [Thread-4] (Running)
	Thread [Thread-5] (Running)
	Thread [Thread-9] (Running)
	Thread [Thread-12] (Running)
	Thread [Thread-13] (Running)
	Thread [Thread-14] (Running)
	Thread [Thread-15] (Running)
	Thread [Thread-16] (Running)
	Thread [Thread-17] (Running)
	Thread [Thread-18] (Running)
	Thread [Thread-19] (Running)

Server-side threads (yes, I'm running DS from JBoss):
org.jboss.Main at localhost:4078
	System Thread [Finalizer] (Running)
	System Thread [Reference Handler] (Running)
	System Thread [Signal Dispatcher] (Running)
	Thread [DestroyJavaVM] (Running)
	Thread [Timer-0] (Running)
	Thread [ScannerThread] (Running)
	Thread [SocketAcceptor-0] (Running)
	Thread [DatagramAcceptor-1] (Running)
	Thread [JBossLifeThread] (Running)
	Thread [LeaderFollowerThreadPool-1] (Running)
	Thread [PooledByteBufferExpirer-0] (Running)
	Thread [SocketAcceptorIoProcessor-0.0] (Running)
	Thread [AnonymousIoService-3-14] (Running)

And here's the netstat output:
$ netstat -a|grep ldap
  TCP    nasenbaer:ldap         nasenbaer:0            ABHOEREN
  TCP    nasenbaer:ldap         localhost:3273         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3277         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3323         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3327         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3331         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3401         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3405         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3470         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3474         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3478         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3566         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3570         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3574         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3578         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3582         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3878         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3969         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3985         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:3988         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4022         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4072         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4076         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4080         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4084         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4088         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4180         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4184         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4188         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4192         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4196         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4317         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4321         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4325         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4329         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4333         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4447         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4455         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4459         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4463         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4467         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4865         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4869         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4873         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4877         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4881         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4899         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4903         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4913         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4914         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4915         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4940         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4944         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4948         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4950         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4952         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4956         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4958         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4961         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4964         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4967         HERGESTELLT
  TCP    nasenbaer:ldap         localhost:4970         HERGESTELLT
  TCP    nasenbaer:3875         localhost:ldap         HERGESTELLT
  TCP    nasenbaer:3878         localhost:ldap         HERGESTELLT

> Reliable hang of DS during query
> --------------------------------
>
>          Key: DIRSERVER-586
>          URL: http://issues.apache.org/jira/browse/DIRSERVER-586
>      Project: Directory ApacheDS
>         Type: Bug

>  Environment: DS 0.9.3, Windows, JDK 1.5
>     Reporter: Jörg Henne
>     Assignee: Alex Karasulu
>  Attachments: bugreport.zip
>
> When running the attached test, the directory server hangs after executing a slew of
operations when searching for objects.
> First of all, some background on the test case:
> The attached test case (in the form of an exported eclipse project) is, unfortunately,
based on quite a few classes. They are part of a project I am currently working on: an object
to ldap mapper with a similar approach as castor for XML or hibernate for RDBMS, albeit a
lot more modest in complexity (I'll, hopefully, one day be able to open-source it - for now
it is still much to immature). I have supplied all that stuff mainly for your reference.
> To run the test case, please make sure that the constant "URL" in LDAPDirectoryTest points
to a valid directory. The URL the context points to must exist. It will, however, subsequently
create lots of nodes below it.
> The hang seems to be related to some kind of deadlock, since it doesn't occur once the
whole test is run via a single context only. To achieve this, set the constant "ONE_CONTEXT"
to true (each LDAPDirectory uses its own set of contexts).
> If you have any problems running the test, please don't hesitate to contact me.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message