[ 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
|