Hi, solved the problem on my own. It was the linux implementation of Securenumber class that froze the whole tomcat.
Adding "-Djava.security.egd=urandom" to the start command solved the problem. Nicolai -----Ursprüngliche Nachricht----- Von: Nicolai Bieber [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 17. Dezember 2003 17:27 An: [EMAIL PROTECTED] Betreff: Tomcat (embedded in JBoss) hangs during startup of SSL connector Hi there, I've encountered a strange problem while starting jboss 3.2.1 (including tomcat 4.1.24) with the SSL-Connector enabled on port 443: Symptom: The server hangs while initializing the SSL-connector and never comes back (at least not for several hours). So the whole start-up processes is frozen. The last two lines in the log are: 2003-12-17 13:24:08,268 DEBUG [org.apache.coyote.http11.Http11Protocol] Attribute sslImplementation: null 2003-12-17 13:24:08,268 DEBUG [org.apache.tomcat.util.threads.ThreadPool] Getting new thread data This only occurs on two servers of a customer of ours. The same setup works out just fine on other servers. The configuration is: Suse Linux 7.3 (that is kernel 2.4.10) JBoss 3.2.1 with Tomcat 4.1.24 j2sdk 1.4.2_01 Tomcat listens to port 80 and 443 (just commented out the SSL-Connector in the config file) Security patch of US_export_policy.jar;local_policy.jar for strong encryption was done (and undone withaout any change) I already tried this without any success: - using another port for SSL (80, 8443, 9443) - j2sdk 1.4.2_03, j2sdk 1.4.1_05 - different keystore files - using wrong password => tomcat gives correct exception But: The server starts if operated with JDK 1.3.1_01 but that's unfortunaly no option for our application. I already thought about using the newest JBoss 3.2.3 with the Tomcat 4.1.29, because I saw some serious refactoring in the SSL support (separate classes for JDK 1.4). Due to the fact, that we have about 30 installation of our software based on JBoss 3.2.1 and the new version would have been tested intensivly, the update is not a short term solution. I also filled up the tomcat code with debug output and so I found that the line that actually hangs is: context.init(kmf.getKeyManagers(), tm, new java.security.SecureRandom()); in the initProxy() method of org.apache.tomcat.util.net.jsse.JSSESocketFactory >From there it goes into SUN's JSSE-Provider (and never comes back). By the way: If I go through the JSSE code I see obvious (as it seems) infinite loop, which would explain initProxy() invokes SSLContext.init(...) in SSLContext, which just delegates to SSLContextSpi.engineInit(...), which is a abstract method only implemented by SSLContextSpiWrapper.engineInit(...), where we find return statement, but a invokation of SSLContext.init(...) at the end of the method, that makes the circle perfect. On the other hand: How does this work out on all the other installations? May I be tricked by the decompiler? Nicolai --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]