Description of problem: Using org.apache.coyote.http11.Http11NioProtocol as HTTP protocol handler in EAP 6.3.0.ER9 run with security manager on OpenJDK 7u55 leads to the following exception. ERROR [org.apache.catalina.connector] (http-/127.0.0.1:8080-8) JBWEB001018: An exception or error occurred in the container during the request processing: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "setContextClassLoader") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_55] at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_55] at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_55] at java.lang.Thread.setContextClassLoader(Thread.java:1503) [rt.jar:1.7.0_55] at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:218) at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:231) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:935) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] How reproducible: Everytime Steps to Reproduce: 1. Set up HTTP connector like this: <connector name="http" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="http" socket-binding="http" /> 2. Start EAP and access the http://localhost:8080/ Actual results: Exception is thrown and logged. Expected results: No exception thrown. Additional info: The exception is neither thrown for OpenJDK 7u60 nor for Oracle JDK 7u51
Updating status. The same problem is in IBM JDK 7 (and EAP 6.3.0.ER10). Moving under the Web component.
The same problem is in OracleJDK 1.8. See: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-as-testsuite-RHEL-matrix-OracleJDK8-SM/1/jdk=jdk1.8,label_exp=RHEL6%26%26x86/testReport/org.jboss.as.test.manualmode.web.websocket/WebsocketTestCase/websocketTest/
Issue is still valid for EAP 6.3.0.ER10 bits.
Seen in EAP 6.3.1.CP.CR1
After starting with the other issues, I'm moving on with connector and websockets issues. This one could be an issue with the connector misbehaving after the initial request. Anyway if you want to look at it right now and you find something, I have nothing against that.
I have been looking into NIO connector code but did not found anything suspicious. The root case of the failure is that the relevant AccessControlContext.optimize() results with a stack containing empty ProtectionDomain [null,null]. I have built latest OpendJDK8 from sources to debug the issue but with that the issue is not reproducible - connector works as expected. So maybe a bug in JDK which has been fixed upstream?
Seems that we are hitting the same problem as here: https://issues.apache.org/jira/browse/SSHD-332 The NioEndpoint.DefaultThreadFactory.newThread() is invoked in an sun.misc.InnocuousThread which has associated empty protection domain. The empty protection domain is than inherited in the Thread created by the DefaultThreadFactory and this is what is causing the security exception. Creating the thread in a privileged block solves the problem.
Maybe. But the thing I don't like in this bug report is that it shouldn't be running this stack trace at all doing regular keepalive.
Created attachment 946971 [details] NioEndpoint.java 7.5.x branch patch
Same patch applies to 7.4 branch as well (BZ1161125).
So in the meantime I heard it couldn't be reproduced. If it is a real bug, then see my previous comment: this shouldn't be happening at all. So it is weird.
I don't understand why this didn't stay as NEW rather than POST since no fix has been integrated. The analysis: - This would be limited to one JDK despite any reasonable logic - I verified that for a request to http://localhost:8080/ it doesn't enter event mode as demonstrated in the stack trace from the description (which would be a huge bug) So I am setting the nack flag since I don't see any problem at the moment.
I can still reproduce it using latest 6.x build (19db471fec5a50b138544a9c69a847b605a92ac8) on JDK 1.7.0_71 OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) and Oracle JDK 1.8.0_20-b26.
Ok, let's not waste time in pointless discussions, I get the idea. Patch committed as r2546.
Verified in 6.4.0.DR11