You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Nicolai Bieber <nb...@ai-ag.de> on 2003/12/17 17:27:06 UTC

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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


RE: Tomcat (embedded in JBoss) hangs during startup of SSL connector

Posted by Nicolai Bieber <nb...@ai-ag.de>.
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:nbieber@ai-ag.de]
Gesendet: Mittwoch, 17. Dezember 2003 17:27
An: tomcat-user@jakarta.apache.org
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org