4 Replies Latest reply on Oct 1, 2013 7:14 AM by jaikiran pai

    java burns cpu after Nmap scan

    Volker Zeihs Newbie

      Hi,

      I found an unusual behavior of Wildfly 8.0.0 Alpha.

      After I scan the 8080 port with Nmap and the service/version detection "-sV"
      is enabled,
      the java process of my server uses a lot more cpu resources as usually.
      This condition is permanent.

      nmap -sV -p 8080 -v 127.0.0.1

      I test this with:

       

      Wildfly 8.0.0 Alpha 1 and 3
      on Fedora 19 64 bit and
      Windows Server 2012 64 bit

      compiled with OpenJDK 1.7.0

       

      what can I do to fix it?

        • 1. Re: java burns cpu after Nmap scan
          Tomaz Cerar Master

          Hi,

           

          can you try on latest nightly build WildFly nightly builds available

          and if you can still reproduce it, can you post thread dump so we can see where the time is spent.

           

           

           

          --

          tomaz

          • 2. Re: java burns cpu after Nmap scan
            Volker Zeihs Newbie

            Hi,

            thanks for the quick response.

             

            I was able to reproduce the behavior, witch the nightly build

            [Build #690 (Sep 18, 2013 9:27:10 PM)].

             

              $> top -h

             

              PID    USER    PR  NI    VIRT        RES     SHR    S  %CPU %MEM  TIME+   COMMAND     

              17483 zeihs     20   0     3169024  348228  17824  R  99.5     6.2        9:18.92  java        

              17482 zeihs     20   0     3169024  348228  17824  R  99.2     6.2        9:18.69  java 

             

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

            17482 dec -> 444A hex

            17483 dec -> 444B hex

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

             

            thread dump for 444A and 444B:

             

            "default I/O-2" prio=10 tid=0x00007f2e6002d000 nid=0x444b runnable [0x00007f2e269e8000]

               java.lang.Thread.State: RUNNABLE

                at sun.nio.ch.FileChannelImpl.size(FileChannelImpl.java:285)

                - locked <0x00000000e1578708> (a java.lang.Object)

                at sun.nio.ch.FileChannelImpl.transferFrom(FileChannelImpl.java:649)

                at io.undertow.conduits.ReadDataStreamSourceConduit.transferTo(ReadDataStreamSourceConduit.java:30)

                at org.xnio.conduits.ConduitStreamSourceChannel.transferTo(ConduitStreamSourceChannel.java:83)

                at io.undertow.channels.DetachableStreamSourceChannel.transferTo(DetachableStreamSourceChannel.java:67)

                at org.xnio.channels.Channels.drain(Channels.java:807)

                at org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1142)

                at org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1125)

                at io.undertow.channels.DetachableStreamSourceChannel$1.handleEvent(DetachableStreamSourceChannel.java:45)

                at io.undertow.channels.DetachableStreamSourceChannel$1.handleEvent(DetachableStreamSourceChannel.java:33)

                at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)

                at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)

                at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)

                at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)

             

            "default I/O-1" prio=10 tid=0x00007f2e6002b800 nid=0x444a runnable [0x00007f2e26ae9000]

               java.lang.Thread.State: RUNNABLE

                at sun.misc.Unsafe.setMemory(Native Method)

                at sun.misc.Unsafe.setMemory(Unsafe.java:529)

                at sun.nio.ch.Util.erase(Util.java:343)

                at sun.nio.ch.FileChannelImpl.transferFromArbitraryChannel(FileChannelImpl.java:612)

                at sun.nio.ch.FileChannelImpl.transferFrom(FileChannelImpl.java:655)

                at io.undertow.conduits.ReadDataStreamSourceConduit.transferTo(ReadDataStreamSourceConduit.java:30)

                at org.xnio.conduits.ConduitStreamSourceChannel.transferTo(ConduitStreamSourceChannel.java:83)

                at io.undertow.channels.DetachableStreamSourceChannel.transferTo(DetachableStreamSourceChannel.java:67)

                at org.xnio.channels.Channels.drain(Channels.java:807)

                at org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1142)

                at org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1125)

                at io.undertow.channels.DetachableStreamSourceChannel$1.handleEvent(DetachableStreamSourceChannel.java:45)

                at io.undertow.channels.DetachableStreamSourceChannel$1.handleEvent(DetachableStreamSourceChannel.java:33)

                at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)

                at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)

                at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)

                at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)

             

            the full thread dump:

             

            https://community.jboss.org/servlet/JiveServlet/downloadBody/51458-102-1-168436/thread_dump01.txt.zip

            • 3. Re: java burns cpu after Nmap scan
              David Lloyd Master

              The problem is either in Undertow, XNIO, or the JDK itself.  I'm working on replicating the problem in XNIO right now, though so far all my tests are passing (whoever thought a passing test could be disappointing!).

              • 4. Re: java burns cpu after Nmap scan
                jaikiran pai Master

                This will be fixed in WildFly 8.0.0.Beta1 which is being scheduled for release shortly.