tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Dunn <case...@stanford.edu>
Subject Tomcat startup class loading differences
Date Sun, 05 Feb 2006 06:54:31 GMT
Hi,

Tomcat 4.1.24 java 1.4.2_09

We're having an issue with a servlet which makes a secure client-cert 
request to a service.

Some days it works (either 200's or 404's) and others it does not 
(403's) when making a request
to our service.

We're doing nothing but restarting the tomcat each day via cron.same 
.war, same keystore blah blah.

We've extracted the 'requesting code' into a stand alone java applet 
which works consistently - when
running out side of Tomcat on days when the Tomcat-hosted copy of the 
code does not work.

When watching debugging output we see that the servlet fails to even 
attempt to read the keystore
on the days when it fails.

here is a bad request setup:

[Loaded XMLPeek]
[Loaded org.jdom.JDOMException]
[Loaded edu.stanford.coursework.site.SSLDocumentReader]
[Loaded sun.reflect.GeneratedConstructorAccessor21]
[Loaded sun.reflect.GeneratedConstructorAccessor22]
[Loaded com.sun.net.ssl.internal.ssl.SunJSSE_a9 from
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded com.sun.net.ssl.internal.ssl.SunJSSE_a8 from
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded sun.net.www.HeaderParser from /usr/j2sdk1.4.2_09/jre/lib/rt.jar]
java.io.IOException: Server returned HTTP response code: 403 for URL:
https://registry.stanford.edu/d\
oc/courseclass//1066-humbio-7si
       at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:800) 

       at
com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl.getInputStream(Dasho\


A12275)

the previous day, here is a good request setup

[Loaded XMLPeek]
[Loaded org.jdom.JDOMException]
[Loaded edu.stanford.coursework.site.SSLDocumentReader]
[Loaded sun.net.www.protocol.http.Handler from 
/usr/j2sdk1.4.2_09/jre/lib/rt.jar]
[Loaded sun.net.www.protocol.https.Handler from 
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded com.sun.net.ssl.internal.www.protocol.https.Handler from
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded java.net.HttpURLConnection from /usr/j2sdk1.4.2_09/jre/lib/rt.jar]
[Loaded com.sun.net.ssl.HttpsURLConnection from 
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded 
com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl
from /usr/j2sdk1.4.2_09\
/jre/lib/jsse.jar]
[Loaded com.sun.net.ssl.HostnameVerifier from 
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded com.sun.net.ssl.HttpsURLConnection$1 from
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded javax.net.SocketFactory from /usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded javax.net.ssl.SSLSocketFactory from 
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded javax.net.ssl.SSLSocketFactory$1 from 
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl from
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded javax.net.ssl.SSLContextSpi from 
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded com.sun.net.ssl.internal.ssl.SSLContextImpl from
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded com.sun.net.ssl.internal.ssl.Debug from 
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded com.sun.net.ssl.internal.ssl.SSLContextImpl$1 from
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
[Loaded java.security.KeyStore from /usr/j2sdk1.4.2_09/jre/lib/rt.jar]
[Loaded java.security.KeyStore$1 from /usr/j2sdk1.4.2_09/jre/lib/rt.jar]
keyStore is : /etc/leland/keystore.registry
keyStore type is : jks
[Loaded com.sun.net.ssl.internal.ssl.SSLContextImpl$2 from
/usr/j2sdk1.4.2_09/jre/lib/jsse.jar]
init keystore


[ snip = as you may expect lots of stuff follows, and then we have our 
hand shake and our request and whoop de do ]


when tracing the class loading sequence on at tomcat startup we see a 
marked difference on those
days when our requesting servlet fails to initialize the security context.


Why would the startup be so different from day-to-day?




h

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


Mime
View raw message