Security issue in downgrading JBoss EAP 7.4 from Java 11 to Java 8 - jboss

I am fixing some issues while upgrading from PAM/JBPM 7.9 to 7.12 and with JBoss EAP going from 7.3 to 7.4. To make sure my environment mimics the test server, I tried to downgrade from the Java 11 on my machine to the test server's Openjdk version 8. After changing the Java version, I compensated for a few old certificates, reimported them into keystores and debugged a few errors in the the JBoss logs. However, I seem stuck on what seems like a security issue that has the following symptoms:
At the JBoss console the address of the console (https://127.0.0.1:9993/console/index.html) is being noted in the browser as "Not secure".
I cannot log in to Business Central (Login failed: Not Authorized) despite having used add-user to update the password in application-users.properties. I did this in case the file copied from 7.3 was made using a different level of security than the security in my 7.4 installation.
Kieserver cannot interact with Business Central. I used add-user to update the password for the kieserver account as well. The error message for this is
11:28:15,352 WARN [org.kie.server.services.impl.controller.DefaultRestControllerImpl] (KieServer-ControllerConnect) Exception encountered while syncing with controller at http://localhost:8080/business-central/rest/controller/server/default-kieserver error Error while sending PUT request to http://localhost:8080/business-central/rest/controller/server/default-kieserver response code 405
I have seen similar warning when kie-server cannot reach the backend database but the datasource tests fine and I can connect to the database using the kieserver's credentials.
I see a logged error about the same port, but I am not sure if it is related to the EAP console or PAM
11:28:23,080 INFO [org.xnio.nio] (pool-28-thread-1) XNIO NIO Implementation Version 3.8.4.Final-redhat-00001
11:28:23,210 ERROR [org.kie.workbench.common.screens.datasource.management.backend.integration.wildfly.WildflyBaseClient] (pool-28-thread-1) It was not possible to open connection to Wildfly/EAP server.: java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://127.0.0.1:9990. The connection failed
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
at org.kie.workbench.common.screens.datasource.management.backend.integration.wildfly.WildflyBaseClient.testConnection(WildflyBaseClient.java:158)
at org.kie.workbench.common.screens.datasource.management.backend.integration.wildfly.WildflyBaseClient.testConnection(WildflyBaseClient.java:147)
at org.kie.workbench.common.screens.datasource.management.backend.core.wildfly.WildflyDriverProvider.hasStarted(WildflyDriverProvider.java:210)
at org.kie.workbench.common.screens.datasource.management.backend.core.wildfly.WildflyDriverProvider$Proxy$_$$_WeldClientProxy.hasStarted(Unknown Source)
at org.kie.workbench.common.screens.datasource.management.backend.core.impl.DataSourceRuntimeManagerImpl.hasStarted(DataSourceRuntimeManagerImpl.java:199)
at org.kie.workbench.common.screens.datasource.management.backend.core.impl.DataSourceRuntimeManagerImpl$Proxy$_$$_WeldClientProxy.hasStarted(Unknown Source)
at org.kie.workbench.common.screens.datasource.management.backend.DataSourceManagementBootstrap.lambda$getInitializeDeploymentsTask$0(DataSourceManagementBootstrap.java:172)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to http-remoting://127.0.0.1:9990. The connection failed
at org.jboss.as.protocol.ProtocolConnectionUtils.checkFuture(ProtocolConnectionUtils.java:145)
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:125)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:167)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:132)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.getChannel(RemotingModelControllerClient.java:85)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
... 15 more
Caused by: org.xnio.http.RedirectException: XNIO000816: Redirect encountered establishing connection
at org.xnio.http.HttpUpgrade$HttpUpgradeState.handleRedirect(HttpUpgrade.java:513)
at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$1300(HttpUpgrade.java:165)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:468)
at org.xnio.http.HttpUpgrade$HttpUpgradeState.flushUpgradeChannel(HttpUpgrade.java:369)
at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$900(HttpUpgrade.java:165)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$ConnectionOpenListener.handleEvent(HttpUpgrade.java:340)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$ConnectionOpenListener.handleEvent(HttpUpgrade.java:320)
at org.xnio.http.HttpUpgrade$HttpUpgradeState.upgradeExistingConnection(HttpUpgrade.java:315)
at org.xnio.http.HttpUpgrade.performUpgrade(HttpUpgrade.java:144)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$UpgradeListener.handleEvent(HttpUpgradeConnectionProvider.java:174)
at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$UpgradeListener.handleEvent(HttpUpgradeConnectionProvider.java:153)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:599)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:561)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:549)
at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:227)
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:121)
... 25 more
These are my interfaces and socket binding's in standalone.xml
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>
<interface name="unsecure">
<inet-address value="${jboss.bind.address.unsecure:0.0.0.0}"/>
</interface>
</interfaces>
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="iiop" interface="unsecure" port="3538"/>
<socket-binding name="iiop-ssl" interface="unsecure" port="3539"/>
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
</socket-binding-group>
What is the best way to investigate or fix this security issue?

Related

Jboss cli The controller is not available at ip:9990

I tried to connect to jboss with jboss cli client in the some server it works perfect , but from outside the server it show the message error :
Failed to connect to the controller: The controller is not available at ip:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to http-remoting://ip:9990. The connection timed out: WFLYPRT0023: Could not connect to http-remoting://ip:9990 Connection refused
I launch this command :
java -jar jboss-cli-client.jar --connect --controller=serverIp:9990 --user=userNameJboss --password=passwordJboss
file standalone.xml
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:0.0.0.0}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:0.0.0.0}"/>
</interface>
</interfaces>
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
jboos-cli.xml
<jboss-cli xmlns="urn:jboss:cli:3.3">
<default-protocol use-legacy-override="true">remote+http</default-protocol>
<!-- The default controller to connect to when 'connect' command is executed w/o arguments -->
<default-controller>
<protocol>remote+http</protocol>
<host>localhost</host>
<port>9990</port>
</default-controller>
<!-- Example controller alias named 'Test'
<controllers>
<controller name="Test">
<protocol>remote+http</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
-->
<validate-operation-requests>true</validate-operation-requests>
<!-- Command and operation history log configuration -->
<history>
<enabled>true</enabled>
<file-name>.jboss-cli-history</file-name>
<file-dir>${user.home}</file-dir>
<max-size>500</max-size>
</history>
<!-- whether to resolve system properties specified as command argument or operation parameter values
in the CLI VM before sending the operation requests to the controller -->
<resolve-parameter-values>false</resolve-parameter-values>
<!-- Whether to write info and error messages to the terminal output -->
<silent>false</silent>
<!-- Whether to filter out commands and attributes based on user's permissions -->
<access-control>false</access-control>
<!-- Include the prompt with the command into the output for each command executed in non-interactive mode -->
<echo-command>false</echo-command>
<!-- Uncomment to set the command timeout. Element value is in seconds -->
<!-- <command-timeout>30</command-timeout> -->
<!-- Uncomment to display operation responses using JSON syntax.
By default responses are displayed using DMR string syntax. -->
<!-- <output-json>true</output-json> -->
<!-- Configuration of CLI colors. To disable, change <enabled> to false.
Available colors: black, blue, cyan, green, magenta, red, white, yellow and default, which is the terminal's default
foreground color-->
<color-output>
<enabled>true</enabled>
<error-color>red</error-color>
<warn-color>yellow</warn-color>
<success-color>default</success-color>
<required-color>magenta</required-color>
<workflow-color>green</workflow-color>
<prompt-color>blue</prompt-color>
</color-output>
<connection-timeout>30</connection-timeout>
</jboss-cli>
Try increasing the timeout.
./jboss-cli.sh --connect --controller=yourIP:managementHttpPort --timeout=2000
By default cli is configured to connect in 5 sec(500ms) but sometimes due to firewall and latency it takes more than that so I suggest you try 20sec(20000)

Wildfly 18 - WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/server=default-server/http-listener=http' are not available

I am migrating my jboss eap 6 to wildfly 18 as we are moving our application from java 6 to java 8 . I am new to wildfly 18, while starting the server I am getting below error -
09:22:59,671 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/server=default-server/https-listener=https' are not available:
org.wildfly.network.socket-binding.https; Possible registration points for this capability:
/socket-binding-group=*/socket-binding=*
09:22:59,672 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/server=default-server/http-listener=http' are not available:
org.wildfly.network.socket-binding.https; Possible registration points for this capability:
/socket-binding-group=*/socket-binding=*
09:22:59,678 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.**
09:22:59,698 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 18.0.0.Final (WildFly Core 10.0.0.Final) stopped in 13ms
I changed socket bindinfs in standalone.xml file and standalone-ha.xmlAdded Socket binding changes in both files -
As i copied all these sockets from previous jboss eap 6 files.
Can i get explanation why these different 2 socket bindings needed and also worked in jboss?
What capabilities is it searching for? do i need to add some externals?
Need suggestions on this .. Do am i missing something in standalone.xml file? or package in module folder? I am confused, need to solve this issue as soon i can..
Thank you in advance!!
As #Shrishti Jain mentioned socket-binding for http would have not present in both standalone.xml and standalone-ha.xml which could be one possible reason for the error.
There is an another possibility for the above error.
As the console error log('/subsystem=undertow/server=default-server/http-listener=http' are not available) clearly gives a hint that http-listener for listener-name http under subsystem configuration for undertow server with the server name "default-server" is not available or not configured properly. The section you have to check is mentioned below
<!-- subsystem section for undertow server(subsystem=undertow/server) -->
<subsystem xmlns="urn:jboss:domain:undertow:3.1">
<buffer-cache name="default"/>
<!-- server=default-server -->
<server name="default-server">
<!-- http-listener=http -->
<http-listener name="http" socket-binding="http-new" max-post-size="6442450944" redirect-socket="https" enable-http2="true"/>
<https-listener name="https" socket-binding="https" max-post-size="6442450944" security-realm="SSLRealm" enable-http2="true"/>
....
</subsystem>
In the above snippet there are chances where the socket-binding of "http-new" might have not configured properly. In the above case the socket-binding of http-new is not present in <socket-binding-group>
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
....
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
</socket-binding-group>
NOTE:
The issue causing listener's socket-binding configuration should exist in both standalone.xml and standalone-ha.xml files
For this error - https , management-https ports were missing in standalone-ha.xml. We have to sure it should be there in both standalone and standalone-ha xml files.

Wildfly 14 domain - Connection timeout

Situation: Windows 10 Host machine needs to communicate with Fedora 26 virtual machine. Windows 10 is my host in domain, fedora is slave. VirtualBox machine has 2 adapters, one is Bridged, and the other is Internal Network Adapter.
IPv4 of my host machine is: 192.168.0.17
Slave machine IP is: 192.168.0.35
When running domain on Windows, and accessing 192.168.0.17:9990 I can bring up management console. But when starting domain on Fedora, it says Connection timeout, cant connect to remote://192.168.0.17:9990
Picture below is my current situation.
What have I done: I have disabled and stopped firewalld on fedora, iptables aren't running, as I can't even disable them.
I have enabled firewall rule on windows that lets me communicate between host and vm.
I have tried pinging Host machine from Fedora, and it is all good.
I have tried changing ports on <static-discovery/> tag, but it won't ping 9990, nor 9999.
I have tried connecting to host management console via jboss-cli on host machine, and it is working.
I have tried connecting to host management console via jboss-cli on slave machine, and it is working.
My host.xml file on Windows:
<management-interfaces>
<http-interface security-realm="ManagementRealm">
<http-upgrade enabled="true"/>
<socket interface="management" port="${jboss.management.http.port:9990}"/>
</http-interface>
</management-interfaces>
<domain-controller>
<local/>
</domain-controller>
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:192.168.0.17}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:192.168.0.17}"/>
</interface>
<interface name="unsecured">
<inet-address value="192.168.0.17"/>
</interface>
</interfaces>
My host.xml file on slave:
<domain-controller>
<remote security-realm="ManagementRealm">
<discovery-options>
<static-discovery name="master-native" protocol="remote" host="192.168.0.17" port="9999" />
<static-discovery name="master-https" protocol="https-remoting" host="192.168.0.17" port="9993" security-realm="ManagementRealm"/>
<static-discovery name="master-http" protocol="http-remoting" host="192.168.0.17" port="9990" />
</discovery-options>
</remote>
</domain-controller>
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:10.211.55.2}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:10.211.55.2}"/>
</interface>
<interface name="unsecured">
<inet-address value="10.211.55.2" />
</interface>
</interfaces>
I have followed this tutorial: https://docs.jboss.org/author/display/WFLY10/Clustering+and+Domain+Setup+Walkthrough
Following picture is the output on Fedora when starting domain.sh, and output on windows when starting domain.bat
9990 port is for http-remoting not remote protocol (port 9999), change it and try again.
See: Domain Configuration

Changing Wildfly 10 ports when starting from NetBeans

I am facing some very strange behaviour from my WildFly server and after checking everything i'm not sure anymore if i did something wrong or if this is a bug in Wildfly or NetBeans.
I am developing an application which uses two WildFly servers for different tasks, and because i am running both on my development computer, they have to be running on different ports. Until now the system has been running properly on JBoss 7, Java 1.7 and NetBeans 8.0.2.
Now we have decided to switch to WildFly 10, Java 1.8 and NetBeans 8.2.
The previous port configuration was as follows:
Server 1:
-In Netbeans: HTTP Port: 8080, JMX port: 9999
-In standalone.xml:
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="http" port="8080"/>
Server 2:
-In Netbeans: HTTP Port: 8580, JMX port: 10499
-In standalone.xml:
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:500}">
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="http" port="8080"/>
As you can expect this resulted in Server 1 running with the application on port 8080 and with the management console on port 9990 and Server 2 running on port 8580 with the management console on port 10490.
Now for the new system. I got Application 1 to run properly on the default ports without much trouble, but i am having problems with application 2.
My first instinct was of course to configure it in a similar way to the old server, so in NetBeans i set Port 8580 and Management 10490, and in standalone.xml i set an offset of 500.
To my surprise this resulted in the application running on port 9080 and the management console running on 10990.
I am guessing that the reason for this is that NetBeans 8.2 supplies these startup parameters to the WildFly server:
-Djboss.management.http.port=10490 -Djboss.http.port=8580
Then despite what is written in standalone.xml the port where the application runs is 8580+500=9080, and not 8080+500 like it was on the old server.
So my first question is how can i stop NetBeans from sending these parameters to WildFly? I want whatever is written in standalone.xml to be used.
So what i tried next was to remove the port offset from standalone.xml and instead to set
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:10490}"/>
<socket-binding name="http" port="${jboss.http.port:8580}"/>
When i started the server the management console was correctly on port 10490, and when i checked the deployments, i saw that my webservice was deployed and running on port 8580. But when i clicked the link to the WSDL, i got this error in the log:
07:19:07,907 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /mferac/IxDokService: javax.servlet.ServletException: JBWS024029: Cannot obtain destination for /xyz/XyzService
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.findDestination(RequestHandlerImpl.java:173)
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.jrHandle(ServletInitialHandler.java)
at org.zeroturnaround.javarebel.integration.servlet.undertow.cbp.ServletInitialHandlerCBP.handleRequest(ServletInitialHandlerCBP.java:98)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Does anybody have an explanation for why this error should occur? Could you suggest some steps to resolve it?
In addition to the above, i also tried some other configurations, none of which resulted in a working webservice running on port 8580:
Config: Netbeans ports 8580/10490, standalone: offset 0, ports 8580/10490
Result: Management console running on 10490, webservice deployed to 8580, but giving error JBWS024029
Config: NB ports 8580/10490, standalone: offset 500, ports 8080/9990
Result: console on 10990, WS on 9080 and works properly
Config: NB ports 8080/9990, standalone: offset 0, ports 8080/9990
Result: Console on 9990, WS on 8080 and works properly (However this is not a solution because then i can't be running two servers)
Config: NB ports 8580/10490, standalone: offset 0, ports 8080/9990
Result: console on 10490, WS on 8580, but giving error JBWS024029
An idea that i have is that i could set the Netbeans port to 8330 and the offset in standalone to 250, which should cause a working application to be running on port 8580. But to me this feels like some kind of hack and will be very confusing for coworkers trying to re-use my configuration. So i will only use this as a last resort. I also think that i need to find out what error JBWS024029 means before we go into production.
Oh and i just remembered something else. If i just start the server with ports 8580/10490 and then deploy the application from the management console everything works correctly. I only get JBWS024029 if i deploy the application by clicking "Run" on the war project in NetBeans. But in a development environment this is what i will be doing 99% of the time.
Please ignore the last part of the above text, after some further experiments i found out that the JBWS024029 error appears completely randomly regardless of the settings and can be resolved by repeatedly killing and restarting the server until it eventually decides to work.
NetBeans will only use those paramters if your WildFly server is started from NetBeans. Start it manually and then NetBeans will connect to it using the configured port.
Another solution is to remove the expression from the standalone.xml, this way the ports won't be computed from parameters, like this:
<socket-binding name="http" port="8580"/>

bounded-queue-thread-pool threads not getting terminated on jboss shutdown

I have created a bounded-queue-thread-pool in Jboss 7.2.0 standalone.xml as follows:
<subsystem xmlns="urn:jboss:domain:threads:1.1">
<bounded-queue-thread-pool name="myThreadPool">
<core-threads count="6000"/>
<queue-length count="1000"/>
<max-threads count="6000"/>
<keepalive-time time="60" unit="seconds"/>
</bounded-queue-thread-pool>
</subsystem>
After that I am using this as executor in AJP connectors as follows:
<connector name="conn1" protocol="AJP/1.3" scheme="http" socket-binding="conn1" enabled="true" max-post-size="0" executor="myThreadPool" max-connections="2000"/>
<connector name="conn2" protocol="AJP/1.3" scheme="http" socket-binding="conn2" enabled="true" executor="myThreadPool" max-connections="2000"/>
<connector name="conn3" protocol="AJP/1.3" scheme="http" socket-binding="conn3" enabled="true" executor="myThreadPool" max-connections="2000"/>
At the end the socket binding for 3 connectors:
<socket-binding name="conn1" port="15007"/>
<socket-binding name="conn2" port="15008"/>
<socket-binding name="conn3" port="15009"/>
When I start jboss and create multiple http requests, each request thread is created as myThreadPool-threads-1, myThreadPool-threads-2 etc. However when I shutdown jboss using command line, these threads are not getting terminated. Here is the command I use to shutdown:
%JBOSS_HOME%\bin\jboss-cli.bat --connect controller=10.10.54.85:9999 --commands=:shutdown
Due to this, the java process of jboss-AS is not getting killed. However when I simply remove the executor from connector, the java process is terminated successfully. Can someone suggest me how to terminated all the threads of threadPool when server is shutdown?
Probably this bug is a cause of your problem, a workaround is set:
org.apache.coyote.ajp.DEFAULT_CONNECTION_TIMEOUT
Add the following to your system-properties in your host.xml, standalone.xml or domain.xml:
<system-properties>
<property name="org.apache.coyote.ajp.DEFAULT_CONNECTION_TIMEOUT" value="600000"/>
<system-properties>
this works except if we continuously send request to the server.
See also: server hang during shutdown when specifying executor in connector