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)
Related
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?
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.
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
Hi I try to start an standalone keycloak Server within a Docker container.
I set an "env" variable for production, local oder test for that the server connects to the correct MySQL DB.
But upon start up on AWS it seems to ignore the env vars. Localy Dockermachine works fine.
Here is the config setup:
in standalone.xml:
...for (empty) local
<datasource jndi-name="java:/jboss/datasources/KeycloakMysqlDS-default" pool-name="KeycloakMysqlDS-default" enabled="true">
...for production
<datasource jndi-name="java:/jboss/datasources/KeycloakMysqlDS-production" pool-name="KeycloakMysqlDS-production" enabled="true">
...
<provider name="default" enabled="true">
<properties>
<property name="dataSource" value="java:jboss/datasources/KeycloakMysqlDS-${env.env}"/>
....
The 'env' var is verified set to "production" on AWS and empty on local and also reacts in local dockermachine changes.
Just on starting on the AWS dockermachine it uses the default instead of the {env.env} var.
Anyone saw the behaviour before? Or have an idea how to correct it?
Thanks in advance
Gregor
UPDATE:
Well the error does not happen on startup.
It happens several minutes afterwards:
...
WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) IJ000610: Unable to fill pool: java:/jboss/datasources/KeycloakMysqlDS-default: ... Connection refused.
...
So it probably not a problem with the env var.
Instead Keycloak seems to try to open connection to setted datasource... is it true?
Completley another problem...
Keycloak bid to another IP by default. Had to set the ip to 0.0.0.0 to work inside a Docker container.
in configuration.xml...
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:0.0.0.0}"/>
<!--<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>-->
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:0.0.0.0}"/>
<!--<inet-address value="${jboss.bind.address:127.0.0.1}"/>-->
</interface>
</interfaces>
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