Wildfly SWARM - XNIO fails to bootstrap on Azure Platform

[dec42]

I created a very basic Wildfly SWARM Project (Version 2016.12.1, see Attachment).

The Project Features a single REST Endpoint and a few dependencies we would like to use in the future, but are in no way implemented in the current state of the sample project.

Starting the Ueberjar works on my local DEV machine with both, the latest Versions of Windows 10 and Linux Mint, however, as soon as I try to start it within Azure (Standard Webapp Package, latest Java 1.8 and no fancy setup I would be aware of) XNIO fails to bootstrap with the following exceptions:

Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found

and

NIO007004: No functional selector provider is available

I'am kinda lost here, since the XNIO class which produces the Providers will swallow all exceptions, even on trace level logging

XNIO Context:

xnio/NioXnio.java at 3.x · xnio/xnio · GitHub

Any hints on this one?

I guess ill have to implement a custom version of XNIO in order to get the actual exception.

[jaikiran]

What's the JRE vendor and version running on that Azure system? Can you post the output of java -version from there?

[ctomc]

That is really odd.

you could force a selector by passing -Dxnio.nio.selector.provider=<name-of-selector>

but without knowing platform / jdk it is hard to say what selector should be forced.

[dec42]

JRE should be fine, JAVA_HOME yields the expected 1.8_xxx and I also tried the versions of different vendors which are available on Azure.

I've also set the IP4Stack Argument, that's a requirement by Azure Platform.

-------------------------------------------------------

Update:

I implemented a custom Version of XNIO to catch the actual exception:

2017-01-13 09:08:49,244 INFO  [org.jboss.gravia.runtime] (MSC service thread 1-2) Started: Module[gravia-container-wildfly-extension:1.3.1]

2017-01-13 09:08:49,275 INFO  [org.wildfly.extension.camel] (MSC service thread 1-2) Bound camel naming object: java:jboss/camel/CamelContextFactory

2017-01-13 09:08:49,291 INFO  [org.wildfly.extension.camel] (MSC service thread 1-2) Bound camel naming object: java:jboss/camel/CamelContextRegistry

2017-01-13 09:08:49,634 INFO  [org.xnio.nio] (MSC service thread 1-1)

DEFAULT PROVIDER:

java.io.IOException: Unable to establish loopback connection

  ... nio stack ...

Caused by: java.net.SocketException: Address family not supported by protocol family: bind

  at sun.nio.ch.Net.bind0(Native Method)

  at sun.nio.ch.Net.bind(Net.java:433)

  at sun.nio.ch.Net.bind(Net.java:425)

  at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)

  at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)

  at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)

  at sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:121)

  at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:76)

  ... 28 more

From the Azure Sandbox Wiki:

The only way an application can be accessed via the internet is through the already-exposed HTTP (80) and HTTPS (443) TCP ports; applications may not listen on other ports for packets arriving from the internet.
However, applications may create a socket which can listen for connections from within the sandbox. For example, two processes within the same app may communicate with one another via TCP sockets; connection attempts incoming from outside the sandbox, albeit they be on the same machine, will fail. See the next topic for additional detail.

Connection attempts to local addresses (e.g. localhost, 127.0.0.1) and the machine's own IP will fail, except if another process in the same sandbox has created a listening socket on the destination port.

Rejected connection attempts, such as the following example which attempts to connect to 127.0.0.1:80, from .NET will result in the following exception:

Azure Web App sandbox · projectkudu/kudu Wiki · GitHub

So my guess is that XNIO tries to bind against some default like %machine_name% (Public Address) which would be disallowed by the Azure Sandbox.

I will investigate further.

Perhaps someone has any hints on how to set something like an "XNIO Bind Address"?

"-D swarm.bind.address=localhost" did not fix the issue.

[ctomc]

if you think only that is the problem, just force wildfly to bind to different ip.

when you run it add -b 0.0.0.0 or whatever ip you want.

so standalone.sh / .bat -b <ip-to-bind-to>

similar for binding management interface use -bmanagment <ip>

Another option is to edit standalone.xml under section <interface>

[dec42]

Hey Tomaz,

thanks for the input, I tried both -b 127.0.0.1 and -Dswarm.bind.address=127.0.0.1

XNIO still fails on the socket binding, so I guess its not related to the bind address and more of a port problem.

Greetings Simon

[jaikiran]

Is it using IPv6 to bind the socket? If so, try forcing the JVM to use IPv4 by setting -Djava.net.preferIPv4Stack=true system property

[dec42]

Hi jaikiran pai,

i have already made sure to pass the IPv4Stack Argument to the Application. Its shown in the trace.log above:

2017-01-10 02:24:00,678 INFO  [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0029: Install MSC service for command line args: [-Dswarm.logging=TRACE, -Dswarm.http.port=11815, -Djava.net.preferIPv4Stack=true]

[dec42]

I will answer my own question:

My guess is that a name change of the originally deployed war (eg dummy1-swarm.jar -> dummy2-swarm.jar) lead to the port being blocked, even after I killed the process.

Starting dummy2-swarm.jar or for that reason the demo-swarm.jar from above then lead to the exception described in this thread.

A clean restart of the VM trough the Azure Portal helped in my case.