Nigel and I had detailed discussion on this issue, following is our analysis:
The root cause of this problem appears to be the following exception in which the "Grizzly proxy", after it has accepted a client connection in behalf of the portmapper, passes the SocketChannel to the port mapper itself.
at java.lang.Class.getDeclaredMethods0(Native Method)
We can only suggest that the NoClassDefFoundError is a JRockit bug (a similar NoClassDefFoundError occurs in a Shoal thread at about the same time).
The result of this exception will cause the MQ client to hang whilst reading data from the port mapper. The socket has been established but no data is being returned. As a result the application's call to createConnection() will block.
This is taking place whilst the connection pool is being enlarged. We notice that due to the connection pool holding various locks whilst this is taking place, all other connection pool activity (including closing connections) will block as well.
The JVM issue has been logged in bugster http://monaco.sfbay.sun.com/detail.jsf?cr=7011216.
There is not much we can do on this bug but to wait and watch until the JVM issue is resolved.