JVM hang

Discussions

Performance and scalability: JVM hang

  1. JVM hang (2 messages)

    I'm not sure this is the good place for this post, but we have a problem on production server running java 1.4.1 on RedHat.

    Here is the problematic thread stack trace :

    "Thread-151638" daemon prio=1 tid=0x0x6a8de2f0 nid=0x616d waiting on condition [6dd7e000..6dd7f210]
            at java.util.Vector.remove(Vector.java:797)
            - waiting to lock <0x47d9ed80> (a atchik.util.DBConnectionManager$DBConnectionPool$LIFO)
            at atchik.util.DBConnectionManager$DBConnectionPool$LIFO._pop(DBConnectionManager.java:471)
            at atchik.util.DBConnectionManager$DBConnectionPool$AStack.pop(DBConnectionManager.java:445)
            - locked <0x47d9ed80> (a atchik.util.DBConnectionManager$DBConnectionPool$LIFO)

    The "LIFO" object extends Vector and implements pop/push methods which are synchronized (on the Vector instance, here 0x47d9ed80), so it enter the pop method with the lock but wait later for this lock in the remove Vector method ???

    public class AStack extends Vector {
        public abstract Object _pop();
        public synchronized Object pop() {
           ...
           Object o = _pop();
        }
    }

    public LIFO extends AStack {
        public Object _pop() { remove(size()-1); }
    }

    Threaded Messages (2)

  2. JVM hang[ Go to top ]

    assuming you implemented something like this:

     class Stack extends Vector {
            synchronized void push(Object obj) {
                add(0, obj);
            }
            
            synchronized Object pop() {
                if (size() > 0) {
                    return remove(0);
                }
                return null;
            }
        }

    you shouldn't have any issues. However, as is often the case with implementing your own synchronization strategies, especially on top of a class that already has its own synchronization, you can often run into issues.

    Real question is, why didn't you use java.util.Stack?
  3. Because we want to be able to configure the stack policy LIFO/FIFO.

    We have re implement the stack using a simple ArrayList with our own synchronization methods and it seems all is working fine on this side.

    I'm sure there is another problem which is perhaps a JVM bug. Here is a new stack trace we have had yesterday on our production server :

    "reaper:handler" daemon prio=1 tid=0x0x695d4148 nid=0x7261 in Object.wait() [69a7e000..69a7ef90]
            at java.lang.Object.wait(Native Method)
            - waiting on <0x47cedbd0> (a java.util.Hashtable)
            at org.webmacro.broker.ResourceManager$1.run(ResourceManager.java:164)
            - locked <0x47cedbd0> (a java.util.Hashtable)

    "reaper:user" daemon prio=1 tid=0x0x695c3488 nid=0x7261 in Object.wait() [699fe000..699ff010]
            at java.lang.Object.wait(Native Method)
            - waiting on <0x47cedc68> (a java.util.Hashtable)
            at org.webmacro.broker.ResourceManager$1.run(ResourceManager.java:164)
            - locked <0x47cedc68> (a java.util.Hashtable)

    "reaper:template" daemon prio=1 tid=0x0x695c3330 nid=0x7261 in Object.wait() [6997e000..6997f090]
            at java.lang.Object.wait(Native Method)
            - waiting on <0x47cd00c0> (a java.util.Hashtable)
            at org.webmacro.broker.ResourceManager$1.run(ResourceManager.java:179)
            - locked <0x47cd00c0> (a java.util.Hashtable)

    "reaper:config" daemon prio=1 tid=0x0x695cc980 nid=0x7261 in Object.wait() [698ff000..698ff110]
            at java.lang.Object.wait(Native Method)
            - waiting on <0x47cd04f8> (a java.util.Hashtable)
            at org.webmacro.broker.ResourceManager$1.run(ResourceManager.java:179)
            - locked <0x47cd04f8> (a java.util.Hashtable)

    In this product we are using Webmacro (old version) and all threads are waiting for a lock they already have !