|
Running MyApacheDS10Test on ApacheDS RC 1.0 & different VMs.
SUN 1.4.2 & SUN 1.5 =================== OK Starting LDAP Directory service log4j:WARN No appenders could be found for logger (org.apache.directory.shared.l dap.name.DnParser). log4j:WARN Please initialize the log4j system properly. LDAP Directory service started. in testMe() exiting testMe Test PASSED BEA 1.4.2 ========= Test hangs with the following output: Starting LDAP Directory service log4j:WARN No appenders could be found for logger (org.apache.directory.shared.l dap.name.DnParser). log4j:WARN Please initialize the log4j system properly. LDAP Directory service started. in testMe() javax.naming.CommunicationException: Request: 1 cancelled at com.sun.jndi.ldap.LdapRequest.getReplyBer()Lcom.sun.jndi.ldap.BerDeco der;(LdapRequest.java:60) at com.sun.jndi.ldap.Connection.readReply(Lcom.sun.jndi.ldap.LdapRequest ;)Lcom.sun.jndi.ldap.BerDecoder;(Connection.java:405) at com.sun.jndi.ldap.LdapClient.ldapBind(Ljava.lang.String;[B[Ljavax.nam ing.ldap.Control;Ljava.lang.String;Z)Lcom.sun.jndi.ldap.LdapResult;(LdapClient.j ava:340) at com.sun.jndi.ldap.LdapClient.authenticate(ZLjava.lang.String;Ljava.la ng.Object;ILjava.lang.String;[Ljavax.naming.ldap.Control;Ljava.util.Hashtable;)L com.sun.jndi.ldap.LdapResult;(LdapClient.java:193) at com.sun.jndi.ldap.LdapCtx.connect(Z)V(LdapCtx.java:2640) at com.sun.jndi.ldap.LdapCtx.<init>(Ljava.lang.String;Ljava.lang.String; ILjava.util.Hashtable;Z)V(LdapCtx.java:290) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Ljava.lang.String;Ljava. util.Hashtable;)Ljavax.naming.directory.DirContext;(LdapCtxFactory.java:175) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs([Ljava.lang.String;Ljav a.util.Hashtable;)Ljavax.naming.directory.DirContext;(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Ljava.lang.Object ;Ljava.util.Hashtable;)Ljavax.naming.directory.DirContext;(LdapCtxFactory.java:1 36) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(Ljava.util.Hashtab le;)Ljavax.naming.Context;(LdapCtxFactory.java:66) at javax.naming.spi.NamingManager.getInitialContext(Ljava.util.Hashtable ;)Ljavax.naming.Context;(NamingManager.java:662) at javax.naming.InitialContext.getDefaultInitCtx()Ljavax.naming.Context; (InitialContext.java:243) at javax.naming.InitialContext.init(Ljava.util.Hashtable;)V(InitialConte xt.java:219) at javax.naming.InitialContext.<init>(Ljava.util.Hashtable;)V(InitialCon text.java:195) at javax.naming.directory.InitialDirContext.<init>(Ljava.util.Hashtable; )V(InitialDirContext.java:80) at MyApacheDS10Test.testMe()V(MyApacheDS10Test.java:84) at MyApacheDS10Test.main([Ljava.lang.String;)V(MyApacheDS10Test.java:103 ) BEA 1.5 ======= Hangs with the message: Starting LDAP Directory service log4j:WARN No appenders could be found for logger (org.apache.directory.shared.l dap.name.DnParser). log4j:WARN Please initialize the log4j system properly. LDAP Directory service started. in testMe() javax.naming.CommunicationException: Request: 1 cancelled at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:60) at com.sun.jndi.ldap.Connection.readReply(Connection.java:405) at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:340) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:192) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2637) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:283) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193 ) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.ja va:136) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.jav a:66) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:6 67) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247 ) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.<init>(InitialContext.java:197) at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.jav a:82) at MyApacheDS10Test.testMe(MyApacheDS10Test.java:84) at MyApacheDS10Test.main(MyApacheDS10Test.java:103) Seems pretty strange...
0.9.3 is badly outdated, as 1.0-RC1 is out and I'm not certain we will maintain it. (as far as I know ...) 1.0-RC1 problems you have seem more or less related to JVM classes : when you look at the stacktraces, we are not even dealing with any Apache Directory class or method. It could be interesting that you switch ApacheDS to debug mode to get more informations about what's going on. The problem is that log4j initialisation is failing :) Did you tried to add a -Dlog4j.configuration=<a log4j config file> to the java CL ? I would be very please to have this server side log. Or I will have to download those two JVMs ;-) Another question is : are they JRockit JVM ? Which specific version ? Ok, I've downloaded both JRockit JVM :
jrockit-j2re1.4.2_08 and jrockit-R26.3.0-jre1.5.0_06 for Linux (I don't do W$) I've tested 1.0-RC1 built with these JVM with the MyApacheDS10Test.java. Here is what I get : jrockit-R26.3.0-jre1.5.0_06 : --------------------------------------- Starting LDAP Directory service LDAP Directory service started. in testMe() exiting testMe Test PASSED jrockit-j2re1.4.2_08 : ---------------------------- Not tested yet, because it means recompiling Mina and all other jars using this library. I definitively don't get the error you have with 1.5 JDK, so I bet it has to be tested on Windows. I don't do Windows, sorry... Any kindfull people to test it and possibly bring some more logs on Windows with both JDK ? Emmanuel,
Please the attached logs. I use following BEA VMs: 1. java version "1.4.2_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 2. java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75, GC: System optimized over throughput (initial strategy singleparpar)) Alexei Thanks Alexei.
What we have is something related to a socket being brutally closed : org.apache.mina.common.RuntimeIOException: java.net.SocketException: java.net.SocketException: Connection aborted by peer I don't know if you can reproduce this "behavior" with the latest version of JRockit JVM (rockit-j2re1.4.2_08 and jrockit-R26.3.0-jre1.5.0_06). I don't think that we can tell that ApacheDS or Mina are guilty if the socket is being closed while it's trying to send data. May be you can post something to BEA dev2dev mailing list about your issue? I keep the JIRA open right now, as some people can add some information. It could also be ggod to post the issue to the MINA JIRA, as it may be related to mina more that ADS, even if I don't think that MINA is the cause of your problem. I'm trully sorry not to have a straight response, but this is quite a complicated issue and it may occurs on some very specific configuration (Windows XP with some old Jrockit JVM), configuration I can't install (I only have one computer and it's running Linux) From now on, could you just try the latest JRokit versions and send us a feendback if it's not working well ? Thanks a lot ! Hi Emmanuel,
I have tried most recent win32 versions of JRockit available at bea.com. Here are test results: jrockit-R26.3.0-jre1.5.0_06: 1. MyApacheDSTest (ApacheDS 0.9.2) hangs with 30% probability (20:6) 2. MyApacheDSTest (ApacheDS 0.9.3) works well 3. MyApacheDS10Test (ApacheDS 1.0 RC1) works well jrockit-j2re1.4.2_08: 4. MyApacheDSTest (ApacheDS 0.9.2) hangs on jrockit-j2re1.4.2_08 with 30% probability (20:6) 5. MyApacheDSTest (ApacheDS 0.9.3) works well 6. MyApacheDS10Test (ApacheDS 1.0 RC1) hangs with the following stack (the same as with my old version of JRockit 1.4.2): Starting LDAP Directory service LDAP Directory service started. in testMe() javax.naming.CommunicationException: Request: 1 cancelled at com.sun.jndi.ldap.LdapRequest.getReplyBer()Lcom/sun/jndi/ldap/BerDeco der;(LdapRequest.java:60) at com.sun.jndi.ldap.Connection.readReply(Lcom/sun/jndi/ldap/LdapRequest ;)Lcom/sun/jndi/ldap/BerDecoder;(Connection.java:405) at com.sun.jndi.ldap.LdapClient.ldapBind(Ljava/lang/String;[B[Ljavax/nam ing/ldap/Control;Ljava/lang/String;Z)Lcom/sun/jndi/ldap/LdapResult;(LdapClient.j ava:340) at com.sun.jndi.ldap.LdapClient.authenticate(ZLjava/lang/String;Ljava/la ng/Object;ILjava/lang/String;[Ljavax/naming/ldap/Control;Ljava/util/Hashtable;)L com/sun/jndi/ldap/LdapResult;(LdapClient.java:193) at com.sun.jndi.ldap.LdapCtx.connect(Z)V(LdapCtx.java:2640) at com.sun.jndi.ldap.LdapCtx.<init>(Ljava/lang/String;Ljava/lang/String; ILjava/util/Hashtable;Z)V(LdapCtx.java:290) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Ljava/lang/String;Ljava/ util/Hashtable;)Ljavax/naming/directory/DirContext;(LdapCtxFactory.java:175) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs([Ljava/lang/String;Ljav a/util/Hashtable;)Ljavax/naming/directory/DirContext;(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Ljava/lang/Object ;Ljava/util/Hashtable;)Ljavax/naming/directory/DirContext;(LdapCtxFactory.java:1 36) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(Ljava/util/Hashtab le;)Ljavax/naming/Context;(LdapCtxFactory.java:66) at javax.naming.spi.NamingManager.getInitialContext(Ljava/util/Hashtable ;)Ljavax/naming/Context;(NamingManager.java:662) at javax.naming.InitialContext.getDefaultInitCtx()Ljavax/naming/Context; (InitialContext.java:243) at javax.naming.InitialContext.init(Ljava/util/Hashtable;)V(InitialConte xt.java:219) at javax.naming.InitialContext.<init>(Ljava/util/Hashtable;)V(InitialCon text.java:195) at javax.naming.directory.InitialDirContext.<init>(Ljava/util/Hashtable; )V(InitialDirContext.java:80) at MyApacheDS10Test.testMe()V(MyApacheDS10Test.java:84) at MyApacheDS10Test.main([Ljava/lang/String;)V(MyApacheDS10Test.java:103 ) See the log attached. This log seems to be identical with the log from my previous version of JRockit. So since ApacheDS 0.9.2 is not going to be supported anymore we have only one open issue - ApacheDS 1.0 RC1 on jrockit-j2re1.4.2_08@win32. However, version 0.9.3 works well. Alexei I'm afraid there is nothing we can do with your problem... It seems to be a JVM bug, in 1.5.
As it has been shown by the tests you did on 1.4 JVM, changing the version solved the problem. And 1.5 JVM (JRockit) works well for me on Linux. The stack trace is pretty explicit : Caused by: java.net.SocketException: java.net.SocketException: Connection aborted by peer at jrockit.net.SocketOpts.setOption(ILjava.lang.Object;Ljava.io.FileDescriptor;Ljrockit.net.SocketNativeIO;)V(Unknown Source) at jrockit.nio.ch.SocketChannelImpl$SocketAdaptor.setTrafficClass(I)V(Unknown Source) at org.apache.mina.transport.socket.nio.support.SocketSessionImpl$SocketSessionConfigImpl.setTrafficClass(SocketSessionImpl.java:342) ... 3 more the call that produced the error was in a jrockit class. wdyt ? Any other opinion out there ? Emmanuel,
I have good news: I realize that I have mistakenly downloaded incorrect VM version last time - jrockit-j2re1.4.2_08 is not the most recent one. The most recent is jrockit-R26.3.0-jdk1.4.2_10. Below is the result for this VM: jrockit-R26.3.0-jdk1.4.2_10 1. MyApacheDSTest (ApacheDS 0.9.2) hangs with 16% probability (37:7) 2. MyApacheDSTest (ApacheDS 0.9.3) works well 3. MyApacheDS10Test (ApacheDS 1.0 RC1) works well (!) So BEA guys have done all work for us :) However, I still need a solution to fix (1) since Geronimo unit test still hangs with some probability. Emmanuel, how big is the difference between ApacheDS 0.9.2 API and ADS 0.9.3 API, and between ADS 0.9.2 and ADS 1.0 RC 1? It can probably be some sense to made an intermediate step and initially port Geronimo to 0.9.3 and then (when ADS 1.0 release is ready) finally to ADS 1.0. Can you recommend something? Thanks! That's good news !
Regarding 0.9.2 problems, we do'nt have any solution but a migration to 1.0-RC1. 0.9.x are supposed to be dead branches. We *won't * fix them, because 0.9.3 contains many fixes to 0.9.2, and 1.0-RC1 contains many fixes to 0.9.3. 1.0-RCx are supposed to be bug fixes, and as soon as we haven't reached a stable build (i.e., 1.0), the last version is *always* the best version. As soon as 1.0 is released, then we will be able to maintain it. However, it will always be the same story : 1.0.1 will be a bug fix, and it will be the version to use if you were using 1.0. So, the best advise I can give is to switch urgently to 1.0-RC1, and stop testing 0.9.x versions, which are severly bugged :) FYI, 1.0-RC2 is on its way, and will be available soon (2 weeks ?) Ok, I think we can close this issue now.
Thanks Alexei !
I changed the status to "Invalid" just because it seems to be a JVM issue, not an ApacheDS issue (there is no "closed" choice ...). Btw, we would be very interested by having a feedback from Geronimo team about the way you are using APacheDS and how it behaves. Emmanuel. Hi Emmanuel & directory team,
Can someone from the Directory team upload the most recent ApacheDS jars to the central maven repository? Currently I am working on porting Geronimo to ApacheDS 1.0 RC1. So I need these jars to be located at http://www.ibiblio.org/maven/ in order to be able to build Geronimo with new ApacheDS version. Initially I can suggest the following grouping for these jars (for RC1): groupId=directory-apacheds apacheds-core-1.0-RC1.jar apacheds-core-shared-1.0-RC1.jar apacheds-kerberos-shared-1.0-RC1.jar apacheds-protocol-changepw-1.0-RC1.jar apacheds-protocol-kerberos-1.0-RC1.jar apacheds-protocol-ldap-1.0-RC1.jar apacheds-protocol-ntp-1.0-RC1.jar apacheds-protocol-shared-1.0-RC1.jar apacheds-server-jndi-1.0-RC1.jar apacheds-server-main-1.0-RC1.jar apacheds-server-ssl-1.0-RC1.jar groupId=directory-network mina-core-0.9.2.jar mina-filter-codec-asn1-0.9.2.jar mina-filter-ssl-0.9.2.jar groupId=directory-shared shared-asn1-0.9.5.jar shared-ldap-0.9.5.jar P.S. Does ApacheDS really require such a fresh version of bouncycastle: lcrypto-jdk14-131.jar ? We need to update maven's repo with the latest bouncycastle if so. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Geronimo unit test hangs while running Apache DS on BEA VM
SUN 1.4.2 & SUN 1.5 & BEA 1.5
=============================
Everything is OK. The output is:
Starting LDAP Directory service
[18:44:58] WARN [org.apache.ldap.server.DefaultDirectoryService] - You didn't ch
ange the admin password of directory service instance 'default'. Please update
the admin password as soon as possible to prevent a possible security breach.
[18:44:58] INFO [org.apache.ldap.server.jndi.ServerContextFactory] - LDIF load d
irectory not specified. No LDIF files will be loaded.
[18:44:58] INFO [org.apache.ldap.server.jndi.ServerContextFactory] - Successful
bind of LDAP Service completed: (SOCKET, ldap, 0.0.0.0/0.0.0.0:9389)
LDAP Directory service started.
in testMe()
exiting testMe
Test PASSED
[18:45:00] INFO [org.apache.ldap.server.jndi.ServerContextFactory] - Unbind of L
DAP Service complete: (SOCKET, ldap, 0.0.0.0/0.0.0.0:9389)
BEA 1.4.2
=========
Hangs with the following stack:
[18:02:45] WARN [org.apache.ldap.server.DefaultDirectoryService] - You didn't ch
ange the admin password of directory service instance 'default'. Please update
the admin password as soon as possible to prevent a possible security breach.
[18:02:45] INFO [org.apache.ldap.server.jndi.ServerContextFactory] - LDIF load d
irectory not specified. No LDIF files will be loaded.
[18:02:45] INFO [org.apache.ldap.server.jndi.ServerContextFactory] - Successful
bind of LDAP Service completed: (SOCKET, ldap, 0.0.0.0/0.0.0.0:9389)
LDAP Directory service started.
in testMe()
java.lang.IllegalArgumentException: cannot match with empty pattern
at org.apache.commons.lang.Validate.isTrue(ZLjava.lang.String;)V(Validat
e.java:191)
at org.apache.asn1.ber.digester.TagTree.getNormalNode(Lorg.apache.common
s.collections.primitives.IntStack;)Lorg.apache.asn1.ber.digester.TagNode;(TagTre
e.java:448)
at org.apache.asn1.ber.digester.TagTree.getNode(Lorg.apache.commons.coll
ections.primitives.IntStack;)Lorg.apache.asn1.ber.digester.TagNode;(TagTree.java
:405)
at org.apache.asn1.ber.digester.TagTree.match(Lorg.apache.commons.collec
tions.primitives.IntStack;)Ljava.util.List;(TagTree.java:392)
at org.apache.asn1.ber.digester.RulesBase.match(Lorg.apache.commons.coll
ections.primitives.IntStack;)Ljava.util.List;(RulesBase.java:105)
at org.apache.asn1.ber.digester.BERDigester$DigesterCallback.decodeOccur
red(Lorg.apache.asn1.codec.stateful.StatefulDecoder;Ljava.lang.Object;)V(BERDige
ster.java:199)
at org.apache.asn1.ber.BERDecoder.fireDecodeOccurred(Lorg.apache.asn1.be
r.Tuple;)V(BERDecoder.java:399)
at org.apache.asn1.ber.BERDecoder.decodeValue(Ljava.nio.ByteBuffer;)V(BE
RDecoder.java:226)
at org.apache.asn1.ber.BERDecoder.decode(Ljava.lang.Object;)V(BERDecoder
.java:159)
at org.apache.asn1.ber.digester.BERDigester.decode(Ljava.lang.Object;)V(
BERDigester.java:145)
at org.apache.ldap.common.berlib.asn1.SnickersDecoder.decode(Ljava.lang.
Object;)V(SnickersDecoder.java:98)
at org.apache.ldap.common.message.MessageDecoder.decode(Ljava.lang.Objec
t;)V(MessageDecoder.java:141)
at org.apache.asn1.codec.mina.Asn1CodecDecoder.decode(Lorg.apache.mina.p
rotocol.ProtocolSession;Lorg.apache.mina.common.ByteBuffer;Lorg.apache.mina.prot
ocol.ProtocolDecoderOutput;)V(Asn1CodecDecoder.java:41)
at org.apache.mina.protocol.io.IoAdapter$SessionHandlerAdapter.dataRead(
Lorg.apache.mina.io.IoSession;Lorg.apache.mina.common.ByteBuffer;)V(IoAdapter.ja
va:136)
$
io.IoFilter$NextFilter;Lorg.apache.mina.io.IoSession;Lorg.apache.mina.common.Byt
eBuffer;)V(AbstractIoFilterChain.java:152)
at org.apache.mina.io.AbstractIoFilterChain.callNextDataRead(Lorg.apache
.mina.io.AbstractIoFilterChain$Entry;Lorg.apache.mina.io.IoSession;Lorg.apache.m
ina.common.ByteBuffer;)V(AbstractIoFilterChain.java:372)
at org.apache.mina.io.AbstractIoFilterChain.access$1000(Lorg.apache.mina
.io.AbstractIoFilterChain;Lorg.apache.mina.io.AbstractIoFilterChain$Entry;Lorg.a
pache.mina.io.IoSession;Lorg.apache.mina.common.ByteBuffer;)V(AbstractIoFilterCh
ain.java:51)
at org.apache.mina.io.AbstractIoFilterChain$Entry$1.dataRead(Lorg.apache
.mina.io.IoSession;Lorg.apache.mina.common.ByteBuffer;)V(AbstractIoFilterChain.j
ava:531)
at org.apache.mina.io.AbstractIoFilterChain$1.dataRead(Lorg.apache.mina.
io.IoFilter$NextFilter;Lorg.apache.mina.io.IoSession;Lorg.apache.mina.common.Byt
eBuffer;)V(AbstractIoFilterChain.java:100)
at org.apache.mina.io.AbstractIoFilterChain.callNextDataRead(Lorg.apache
.mina.io.AbstractIoFilterChain$Entry;Lorg.apache.mina.io.IoSession;Lorg.apache.m
ina.common.ByteBuffer;)V(AbstractIoFilterChain.java:372)
at org.apache.mina.io.AbstractIoFilterChain.dataRead(Lorg.apache.mina.io
.IoSession;Lorg.apache.mina.common.ByteBuffer;)V(AbstractIoFilterChain.java:363)
at org.apache.mina.io.IoSessionManagerFilterChain$1.dataRead(Lorg.apache
.mina.io.IoFilter$NextFilter;Lorg.apache.mina.io.IoSession;Lorg.apache.mina.comm
on.ByteBuffer;)V(IoSessionManagerFilterChain.java:77)
at org.apache.mina.io.AbstractIoFilterChain.callNextDataRead(Lorg.apache
.mina.io.AbstractIoFilterChain$Entry;Lorg.apache.mina.io.IoSession;Lorg.apache.m
ina.common.ByteBuffer;)V(AbstractIoFilterChain.java:372)
at org.apache.mina.io.AbstractIoFilterChain.access$1000(Lorg.apache.mina
.io.AbstractIoFilterChain;Lorg.apache.mina.io.AbstractIoFilterChain$Entry;Lorg.a
pache.mina.io.IoSession;Lorg.apache.mina.common.ByteBuffer;)V(AbstractIoFilterCh
ain.java:51)
at org.apache.mina.io.AbstractIoFilterChain$Entry$1.dataRead(Lorg.apache
.mina.io.IoSession;Lorg.apache.mina.common.ByteBuffer;)V(AbstractIoFilterChain.j
ava:531)
at org.apache.mina.io.filter.IoThreadPoolFilter.processEvent(Ljava.lang.
Object;Lorg.apache.mina.common.Session;Lorg.apache.mina.util.EventType;Ljava.lan
g.Object;)V(IoThreadPoolFilter.java:107)
at org.apache.mina.util.BaseThreadPool$Worker.processEvents(Lorg.apache.
mina.util.BaseThreadPool$SessionBuffer;)V(BaseThreadPool.java:410)
at org.apache.mina.util.BaseThreadPool$Worker.run()V(BaseThreadPool.java
:355)
at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Sourc
e)