[
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
