Java threads on OpenVMS sometimes using 100% CPU - VMS

This is a discussion on Java threads on OpenVMS sometimes using 100% CPU - VMS ; Hi, I wrote a Java network application that spawns a thread on each connection and blocks while reading from the network socket. It appears to run fine on Windows. It also runs fine on OpenVMS for a couple of minutes ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Java threads on OpenVMS sometimes using 100% CPU

  1. Java threads on OpenVMS sometimes using 100% CPU

    Hi,

    I wrote a Java network application that spawns a thread on each
    connection and blocks while reading from the network socket.

    It appears to run fine on Windows. It also runs fine on OpenVMS for a
    couple of minutes at 0-10% CPU while accepting and closing
    connections. Then suddenly, seemingly randomly, and only on OpenVMS,
    the process gobbles up 100% CPU. It still appears to run fine but
    once it hits that point it doesn't drop in CPU usage.

    What I don't understand is why this happens when it just appears to be
    a few threads blocking on a few reads. Here is the version
    information:

    > write sys$output f$getsyi("version")

    V8.3

    > java -version

    java version "1.5.0"
    Java(TM) 2 Runtime Environment, Standard Edition
    Classic VM (build 1.5.0-1, 12/07/2005-23:30, native threads, jit)

    And here's a dump of the running thread information I took when it hit
    the 100% CPU state:

    Full thread dump Classic VM (1.5.0-1, native threads):
    "Thread-23" (TID:0x11772a8, sys_thread_t:0x4f192a8, state:R,
    native ID:0x4f5b2c0) prio=5
    at
    net.sourceforge.jsneaker.Http.HttpInputStream.read Line(HttpInputStream.java:
    28)
    at
    net.sourceforge.jsneaker.Http.HttpInputStream.pars eHeader(HttpInputStream.java:
    111)
    at
    net.sourceforge.jsneaker.Http.HttpHandler.run(Http Handler.java,
    Compiled Code)
    "Thread-0" (TID:0x1164930, sys_thread_t:0x4e73650, state:R, native
    ID:0x4eb92c0) prio=5
    at java.io.FileInputStream.readBytes(Native Method)
    at java.io.FileInputStream.read(FileInputStream.java: 194)
    at java.io.BufferedInputStream.fill(BufferedInputStre am.java:
    189)
    at java.io.BufferedInputStream.read(BufferedInputStre am.java,
    Compiled Code)
    at
    net.sourceforge.jsneaker.Http.HttpConsole.run(Http Console.java,
    Compiled Code)
    at java.lang.Thread.run(Thread.java:595)
    "Finalizer" (TID:0x115e720, sys_thread_t:0x4941a58, state:CW,
    native ID:0x49cf2c0) prio=8
    at java.lang.Object.wait(Native Method)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue .java:
    133)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue .java:
    149)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finali zer.java:
    159)
    "Reference Handler" (TID:0x115e4d0, sys_thread_t:0x493ee18,
    state:CW, native ID:0x49952c0) prio=10
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:474)
    at java.lang.ref.Reference$ReferenceHandler.run(Refer ence.java:
    116)
    "Signal dispatcher" (TID:0x115e508, sys_thread_t:0x4919448,
    state:R, native ID:0x494f2c0) prio=5
    "main" (TID:0x115e560, sys_thread_t:0x391df8, state:R, native ID:
    0x7bb5cd40) prio=5
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.ja va:382)
    at java.net.ServerSocket.implAccept(ServerSocket.java :442)
    at java.net.ServerSocket.accept(ServerSocket.java:416 )
    at net.sourceforge.jsneaker.Http.Http.main(Http.java: 10)
    Monitor Cache Dump:
    java.io.BufferedInputStream@115F638/119DBF8: owner
    "Thread-0" (0x4e73650) 1 entry
    java.lang.ref.Reference$Lock@115E4E0/1195D88:
    Waiting to be notified:
    "Reference Handler" (0x493ee18)
    java.net.SocksSocketImpl@1164AA8/11C00F8: owner "main" (0x391df8)
    1 entry
    java.lang.ref.ReferenceQueue$Lock@115E738/11962C0:
    Waiting to be notified:
    "Finalizer" (0x4941a58)
    Registered Monitor Dump:
    utf8 hash table:
    JNI pinning lock:
    JNI global reference lock:
    BinClass lock:
    Class linking lock:
    System class loader lock:
    Code rewrite lock:
    Heap lock:
    Monitor cache lock: owner "Signal dispatcher" (0x4919448) 1 entry
    Thread queue lock: owner "Signal dispatcher" (0x4919448) 1 entry
    Monitor registry: owner "Signal dispatcher" (0x4919448) 1 entry

    I'm not sure if the 23 opened threads (most of which were since shut
    down) caused the problem, is there a way to find out? Or is something
    else obvious from the thread dump? I'm fairly OpenVMS savvy but don't
    know much about what process statistics to look out for.

    I'm going to rewrite the program to use non-blocking sockets so I
    don't need to spawn so many threads anyway, but I wouldn't mind
    learning how to investigate what's going on here.

    Thanks,
    Cody

  2. Re: Java threads on OpenVMS sometimes using 100% CPU

    On Jan 8, 9:10 am, cody.use...@gmail.com wrote:
    > Hi,
    >

    Forget it. I think I found the problem. I'd created the InputStream
    method readLine (to read characters and return only when an EOL marker
    is found), and checked for -1 but didn't return, so it would go into a
    while(true) loop.

    What's poor form about the whole thing on my part is that I fixed the
    exact same problem elsewhere in the code a week ago.

    I didn't suspect it at all because I was so used to the normal
    readLine on the BufferedInputStreams which would spend most of its
    time blocking and never have a stupid mistake like this.

    Cheers,
    Cody

+ Reply to Thread