| Jörg Henne (JIRA) 2006-06-29, 7:11 pm |
| [ http://issues.apache.org/jira/brows...=3Dcomments#ac=
tion_12418534 ]=20
J=C3=B6rg 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 c=
ase which can still (RC3!) be used to trigger hangs and errors in various w=
ays.=20
First of all, a few words on the test case:
- In order to run it, you need a running DS (obviously) and an existing pat=
h in the directory somewhere which can stand some abuse.=20
- 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 connecti=
ons (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 cre=
ating/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, to=
o. Query or not. The second test is based on a clearly broken connection ma=
nagement, but DS should still behave properly. The third test demonstrates =
the hang with a proper (IMHO) connection management, but in a perfectly leg=
al 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
=09System Thread [Finalizer] (Running)
=09System Thread [Reference Handler] (Running)
=09Thread [main] (Running)
=09System Thread [Signal Dispatcher] (Running)
=09Thread [ReaderThread] (Running)
=09Thread [Thread-0] (Running)
=09Thread [Thread-1] (Running)
=09Thread [Thread-4] (Running)
=09Thread [Thread-5] (Running)
=09Thread [Thread-9] (Running)
=09Thread [Thread-12] (Running)
=09Thread [Thread-13] (Running)
=09Thread [Thread-14] (Running)
=09Thread [Thread-15] (Running)
=09Thread [Thread-16] (Running)
=09Thread [Thread-17] (Running)
=09Thread [Thread-18] (Running)
=09Thread [Thread-19] (Running)
Server-side threads (yes, I'm running DS from JBoss):
org.jboss.Main at localhost:4078
=09System Thread [Finalizer] (Running)
=09System Thread [Reference Handler] (Running)
=09System Thread [Signal Dispatcher] (Running)
=09Thread [DestroyJavaVM] (Running)
=09Thread [Timer-0] (Running)
=09Thread [ScannerThread] (Running)
=09Thread [SocketAcceptor-0] (Running)
=09Thread [DatagramAcceptor-1] (Running)
=09Thread [JBossLifeThread] (Running)
=09Thread [LeaderFollowerThreadPool-1] (Running)
=09Thread [PooledByteBufferExpirer-0] (Running)
=09Thread [SocketAcceptorIoProcessor-0.0] (Running)
=09Thread [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=C3=B6rg Henne
> Assignee: Alex Karasulu
> Attachments: bugreport.zip
>
> When running the attached test, the directory server hangs after executin=
g 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, u=
nfortunately, 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 complexi=
ty (I'll, hopefully, one day be able to open-source it - for now it is stil=
l much to immature). I have supplied all that stuff mainly for your referen=
ce.
> To run the test case, please make sure that the constant "URL" in LDAPDir=
ectoryTest 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 o=
ccur 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 se=
t of contexts).
> If you have any problems running the test, please don't hesitate to conta=
ct me.
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|