Bug 39997 - JSVC and APR do not work together for HTTPS connector
JSVC and APR do not work together for HTTPS connector
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Connector:HTTP
5.5.27
Other Linux
: P1 major (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-07-10 00:26 UTC by Rodrigo S de Castro
Modified: 2009-07-17 04:03 UTC (History)
0 users



Attachments
Patch that fixes this bug (3.66 KB, patch)
2009-07-12 14:08 UTC, Mark Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rodrigo S de Castro 2006-07-10 00:26:54 UTC
I use jsvc started by root that forks to a process owned by tomcat user. The
server runs on port 80 and 443. Using jsvc works fine with apr for http (port
80), but for https (port 443) it doesn't. Either it takes ages to run (as stated
by more than one user on tomcat-users as we may see below) or it simply freezes:

http://www.nabble.com/Http11AprProtocol-took-2-hr-to-init-on-http-443-tf1810268.html#a4950939

If we run http with apr protocol, but https as basic protocol, as suggested
above, it works perfectly.

When using jsvc, we have a warning for the JDK, due to some permission problem:

Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location -
 find_vma failed

And this seems to be a jsvc bug related to the lack of permission by the
non-admin user (in my case, tomcat), as we can see here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=38633

For jvsc without apr, everything works fine. The same for apr without jvsc
(running as root user). But SSL simply does not work for me when both are used.

Running "kill -3 pid" for the tomcat process returns the following stack trace:

"main" prio=1 tid=0x08bc6f78 nid=0x966 runnable [0xbf8d4000..0xbf8d4e48]
        at org.apache.tomcat.jni.SSL.initialize(Native Method)
        at org.apache.tomcat.util.net.AprEndpoint.init(AprEndpoint.java:628)
        at org.apache.coyote.http11.Http11AprProtocol.init(Http11AprProtocol.jav
a:115)
        at org.apache.catalina.connector.Connector.initialize(Connector.java:101
6)
        at org.apache.catalina.core.StandardService.initialize(StandardService.j
ava:580)
        - locked <0x891e1ce8> (a [Lorg.apache.catalina.connector.Connector;)
        at org.apache.catalina.core.StandardServer.initialize(StandardServer.jav
a:791)
        at org.apache.catalina.startup.Catalina.load(Catalina.java:503)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:266)
        at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:281)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java
:160)

Please tell me if you need further information.
Comment 1 Rainer Jung 2006-07-10 07:21:08 UTC
Are you able to dump a core of the tomcat process and produce a native stack
dump (e.g. via gdb and "backtrace"? This would help to find out, in which part
of th eunderlying native code we got stuck.

Also: which platform are you on? Which version of OpenSSL do you use? Does your
platform have /dev/random and/or /deb/urandom?
Comment 2 Yoav Shapira 2006-12-24 19:58:04 UTC
Changing status to NEEDINFO pending responses from original poster to Rainer's
questions.
Comment 3 Mark Thomas 2009-07-12 14:07:30 UTC
This appears to be related to the entropy source selected by OpenSSL. I can reproduce similar behaviour with and without the use of jsvc.

I have ported the SSLRandomSeed configuration option from 6.0.x and that fixes this for me with and without jsvc. I'll attach a patch shortly.
Comment 4 Mark Thomas 2009-07-12 14:08:07 UTC
Created attachment 23962 [details]
Patch that fixes this bug

The attached patch has been proposed for 5.5.x
Comment 5 Mark Thomas 2009-07-17 04:03:00 UTC
This has been fixed in 5.5.x and will be included in 5.5.28 onwards.