-
1. Re: Excessive Port Usage by WildFly 8.1.0.Final?
jaikiran Jun 13, 2014 12:56 AM (in response to darrenjones)Is this standalone.xml or standalone-full.xml or something else?
-
2. Re: Excessive Port Usage by WildFly 8.1.0.Final?
ctomc Jun 13, 2014 4:38 AM (in response to darrenjones)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.
-
3. Re: Excessive Port Usage by WildFly 8.1.0.Final?
darrenjones Jun 13, 2014 8:16 AM (in response to jaikiran)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.
-
4. Re: Excessive Port Usage by WildFly 8.1.0.Final?
darrenjones Jun 13, 2014 10:48 AM (in response to 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)