Excessive Port Usage by WildFly 8.1.0.Final?

[darrenjones]

After starting up a vanilla WildFly 8.1.0.Final server on Windows (and doing nothing else), I did a netstat to check the network port usage. I see some unexpected ports in the output that seem to be paired together.

Abbreviated output is in the attachment, but here is the first pair:

  Proto  Local Address          Foreign Address        State           PID

  TCP    127.0.0.1:56673        MachineName:56674      ESTABLISHED     6612

  TCP    127.0.0.1:56674        MachineName:56673      ESTABLISHED     6612

And there are approximately 20 such self-referencing pairs in total.

Can anyone explain what WildFly is using these pairs of ports for?

Thanks.

[jaikiran]

Is this standalone.xml or standalone-full.xml or something else?

[ctomc]

Hey,

as you can see in your ports.txt there are only two listening ports

TCP	127.0.0.1:8080	MachineName:0	LISTENING	6612
TCP	127.0.0.1:9990	MachineName:0	LISTENING	6612

all the others are already established connections.

It is hard to say what exactly they are beyond that they are comming from local host.

that could be anything that connects to wildfly.

either web browser, proxy server, or some other software connecting to it,

That is all i can tell you based on data you posted.

[darrenjones]

Thanks for taking the time to reply. I'm guessing you don't see this behaviour on your environments! To answer your questions:

This is for just standalone.xml.

And the netstat was done just after WildFly started up, before I tried to visit any web pages or otherwise access WildFly's services - so I don't think there can be anything external connecting to WildFly.

Also, the process id of all those ports is the same (i.e. the WildFly java process), which is why I thought that WildFly by itself was responsible for those ports.

[darrenjones]

I found some time to attach a debugger to the WildFly process, and added a breakpoint to the java.net.Socket constructors. I found that the sockets are being constructed by Java NIO, as part of the creation of an XNIO worker thread - this explains why there are so many - it would appear you get a pair of sockets for each thread. This would seem to agree with a comment in the WorkerAdd class saying that each worker thread needs two file descriptors.

I don't fully understand how NIO works, but I feel satisfied that these port pairs are simply an artifact of how Java NIO is implemented.

FYI, the route to the Socket construction is:

at java.net.Socket.<init>(Socket.java:163)

at sun.nio.ch.SocketAdaptor.<init>(SocketAdaptor.java:63)

at sun.nio.ch.SocketAdaptor.create(SocketAdaptor.java:69)

at sun.nio.ch.SocketChannelImpl.socket(SocketChannelImpl.java:139)

at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:132)

at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:44)

at org.xnio.nio.NioXnio$DefaultSelectorCreator.open(NioXnio.java:245)

at org.xnio.nio.NioXnioWorker.<init>(NioXnioWorker.java:93)

at org.xnio.nio.NioXnio.createWorker(NioXnio.java:203)

at org.xnio.Xnio.createWorker(Xnio.java:437)

at org.xnio.Xnio.createWorker(Xnio.java:424)

at org.wildfly.extension.io.WorkerService.start(WorkerService.java:53)

at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)

at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:745)