Bug 969321

Thread dumps generated with a SIGQUIT are logged to:

(v1) ~/jbosseap-6.0/jbosseap-6.0/tmp/jbosseap-6.0.log
(v1) ~/jbossas-7/jbossas-7/tmp/jbossas-7.log
(v2) ~/tmp/jbossas.log
(v2) ~/tmp/jbosseap.log

This is reported to the user by the rhc output.

The server.log file is JBoss's internal log; the logs I mention are used to capture JVM stdout, and it's the JVM's signal handlers which produce these dumps, not JBoss.

Behavior has not changed since v1; this is neither a regression nor a bug.

Thanks.

(In reply to Dan Mace from comment #1)
> Thread dumps generated with a SIGQUIT are logged to:
> 
> (v1) ~/jbosseap-6.0/jbosseap-6.0/tmp/jbosseap-6.0.log
> (v1) ~/jbossas-7/jbossas-7/tmp/jbossas-7.log
> (v2) ~/tmp/jbossas.log
> (v2) ~/tmp/jbosseap.log
> 
> This is reported to the user by the rhc output.
> 
> The server.log file is JBoss's internal log; the logs I mention are used to
> capture JVM stdout, and it's the JVM's signal handlers which produce these
> dumps, not JBoss.
> 
> Behavior has not changed since v1; this is neither a regression nor a bug.
> 
> Thanks.

Looks like broker is telling user to check thread dump file in server.log file.

$ rhc threaddump jbosseaptest
Success
The thread dump file will be available via: rhc tail jbosseaptest -f */logs/server.log -o '-n 250'

In the /var/lib/openshift/.cartridge_repository/redhat-jbosseap/0.0.1/bin/control, you will see the following lines:

function threaddump() {
        <--snip-->
        client_result "Success"
        client_result ""
        client_result "The thread dump file will be available via: rhc tail $OPENSHIFT_APP_NAME -f */logs/server.log -o '-n 250'"
        <--snip-->
}

It is telling user to incorrect file path.

Johnny,

You're right; good catch. Fixed by https://github.com/openshift/origin-server/pull/2705.

Commit pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/15f0855ac3669507860b9afdbdb1181a5ce6486a
Bug 969321: Fix jboss thread dump log file path message

Verified this bug with devenv_3307, and PASS.

[jialiu@jialiu-pc1 ~]$ rhc threaddump jbosseaptest
Success
The thread dump file will be available via: rhc tail jbosseaptest -f /tmp/jbosseap.log -o '-n 250'
[jialiu@jialiu-pc1 ~]$ rhc tail jbosseaptest -f /tmp/jbosseap.log -o '-n 250'
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0xc2811440> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:942)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)
<--snip-->
Heap
 def new generation   total 17792K, used 10407K [0xbc040000, 0xbd380000, 0xc1590000)
  eden space 15872K,  53% used [0xbc040000, 0xbc889ca8, 0xbcfc0000)
  from space 1920K, 100% used [0xbd1a0000, 0xbd380000, 0xbd380000)
  to   space 1920K,   0% used [0xbcfc0000, 0xbcfc0000, 0xbd1a0000)
 tenured generation   total 38784K, used 22662K [0xc1590000, 0xc3b70000, 0xcc040000)
   the space 38784K,  58% used [0xc1590000, 0xc2bb1a20, 0xc2bb1c00, 0xc3b70000)
 compacting perm gen  total 32768K, used 32555K [0xcc040000, 0xce040000, 0xd2640000)
   the space 32768K,  99% used [0xcc040000, 0xce00af48, 0xce00b000, 0xce040000)
    ro space 10240K,  60% used [0xd2640000, 0xd2c52900, 0xd2c52a00, 0xd3040000)
    rw space 12288K,  63% used [0xd3040000, 0xd37e7910, 0xd37e7a00, 0xd3c40000)