|Summary:||JSVC and APR do not work together for HTTPS connector|
|Product:||Tomcat 5||Reporter:||Rodrigo S de Castro <rodsc>|
|Component:||Connector:HTTP||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||Patch that fixes 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.