2

I am attempting to employ the functionality of Deploying to Wildfly 9 in my build process with the Wildfly-Maven plugin. I am unable to deploy the application, due to the following error.

2015-08-29 15:24:55,720 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host

Please see the attached portion of my pom.xml.

<plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-maven-plugin</artifactId>
            <version>1.0.2.Final</version>
            <configuration>
                <username>admin</username>
                <password>password</password>
                <hostname>127.0.0.1</hostname>
                <name> InspiralWeb-1.0-SNAPSHOT.war</name>
                <jbossHome>C:\Wildfly\wildfly-9.0.1.Final</jbossHome>
            </configuration>
            <executions>
                <execution>
                    <phase>install</phase>
                    <goals>
                        <goal>deploy</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

There is no offset for the port in the standalone.xml, so I am sure the port that the management socket binding is on 9990, which is what is expected. It isn't clear if this is an issue with my setup or some network issue, I am running this locally also(as you can probably tell by the hostname).

Thoughts anyone?

Please see the attached Stacktrace

Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to remote://127.0.0.1:9990. The connection failed
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
    at org.wildfly.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:245)
    ... 27 more
Caused by: java.net.ConnectException: JBAS012174: Could not connect to remote://127.0.0.1:9990. The connection failed
    at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:117)
    at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
    at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
    at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
    at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:148)
    at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
    at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
    at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
    ... 29 more
Caused by: java.net.ConnectException: Connection refused: no further information
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:708)
    at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:319)
    at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
    at ...asynchronous invocation...(Unknown Source)
    at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
    at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
    at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
    at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
    at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:78)
    at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:109)
    ... 39 more
broot02
  • 103
  • 1
  • 2
  • 11
  • check the server log for error messages and the binding message for the listener port and address. Maybe it binds to ::1 instead or similar. – eckes Aug 29 '15 at 20:18
  • The exact error message form the server.log is the following..2015-08-29 14:50:20,914 ERROR [org.jboss.remoting.remote.connection] (default I/O-1) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host – broot02 Aug 29 '15 at 20:27
  • And the client side? – eckes Aug 29 '15 at 20:29
  • As far as the listener port/address, this what I found. 2015-08-29 12:36:08,305 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management – broot02 Aug 29 '15 at 20:29
  • I think jboss remoting is not using the http-interface but the native one on 9999 (at least for some older versions, not sure when the protcol upgrade was introduced). – eckes Aug 29 '15 at 20:30
  • I've added the stacktrace. – broot02 Aug 29 '15 at 20:45
  • I wouldn't think it would matter if I was running it in standalone mode, rather than domain mode. Correct? – broot02 Aug 29 '15 at 20:53
  • Not sure what "must be enabled" (_The native API endpoint is co-located with either the a host controller or a standalone server. To use the CLI it must be enabled. By default, it runs on port 9999_) in https://docs.jboss.org/author/display/WFLY8/Admin+Guide#AdminGuide-HTTPManagementEndpoint means. Try telnet to 9999 and using jboss-cli. – eckes Aug 29 '15 at 21:41
  • It doesn't look like that's a WildFly 9 server. Make sure you have WildFly up and running before you attempt a deploy. – James R. Perkins Sep 01 '15 at 20:41

2 Answers2

0

I am not 100% sure as to why, it had to be done this way, but after I started to run in domain mode rather than standalone it started working.

Also what eckes stated was true as well, "Not sure what "must be enabled" (The native API endpoint is co-located with either the a host controller or a standalone server. To use the CLI it must be enabled. By default, it runs on port 9999) in docs.jboss.org/author/display/WFLY8/… means. Try telnet to 9999 and using jboss-cli."

More so than that I had to connect via the CLI to the localhost:9999. This seemingly made it so I could remotely deploy using the maven-wildfly plugin.

There still seems to be some connectivity issues, as it seems to always fail the initial deploy during the install phase, and building the War. So I acknowledge this isn't the best solution at all.

I haven't scourged the standalone.xml vs. the domain.xml to see if certain things are disabled by default in Wildfly 9 Standalone mode, as compared to Domain mode.

broot02
  • 103
  • 1
  • 2
  • 11
0

The reason of the problem could be one of the following:

  • The deployment of any archive (jar, war, ear) through wildfly-maven-plugin plugin will happen only if the WildFly is listening at its management port which is 9990 by default. So make sure that WildFly is listening at its management port.
  • If WildFly is listening at its management port then check if your host file located at %SYSTEM_ROOT%\System32\drivers\etc for windows machine is configured correctly. i.e. your local host is mapped correctly for both IPv4 and IPv6.

127.0.0.1 localhost

::1 localhost

Keshaw Kumar
  • 317
  • 1
  • 4
  • 15