Bug 982921 - There is no output when trying to threaddump an idled app
Summary: There is no output when trying to threaddump an idled app
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Image
Version: 2.x
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Dan McPherson
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-10 06:54 UTC by Meng Bo
Modified: 2015-05-15 00:33 UTC (History)
3 users (show)

Fixed In Version: devenv_4269
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-26 19:07:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Meng Bo 2013-07-10 06:54:51 UTC
Description of problem:
Create an app which supports threaddump. Make the app into idle status. Then try to threaddump the app. 

It will return nothing.

Version-Release number of selected component (if applicable):
rhc-1.11.3
devenv_3471

How reproducible:
always

Steps to Reproduce:
1.Create jboss app
rhc app create jboss1 jbossas-7 
2.Idle the app
oo-admin-ctl-gears idlegear <uuid>
3.Threaddump the app
rhc threaddump jboss1

Actual results:
There is nothing in the output

Expected results:
Should tell user that the app is in idle status.

Additional info:
There is such info when threaddump a stopped app.
$rhc threaddump juvia
RESULT:
juvia stopped

And can get the following info when using rest api.
    <message>
      <severity>error</severity>
      <text>Application is idle, must be started to allow a thread dump</text>
      <exit-code>0</exit-code>
      <field nil="true"></field>
    </message>

Comment 1 Clayton Coleman 2013-07-10 15:29:15 UTC
This is a broker bug - severity "error" should not be returned when a 200 is returned.  Instead, if there is truly an error, it should be communicated via the HTTP status code ALONG with the error message.  There should never be a message with severity "error" on a request that returns 200.

See the email sent around about client_error and client_result.

Comment 2 Lili Nader 2013-07-25 23:01:44 UTC
Clayton,

1. One option is to return a status 409 described below.  The problem with this options is that the broker cannot tell the difference between this type of error and a server error based on the response from the node

"409 Conflict
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. "

2. Another option is to change the code on node to returns this as a CLIENT_MESSAGE which then will be classified as a warning and will be displayed to users regardless of the HTTP status code, right?

I like option 2 better because then all other errors can be classified as 500 (which is not in place today and should be added as part of this bug fix)

Comment 5 Meng Bo 2013-07-26 12:41:02 UTC
Checked on devenv_3564, the result is still incorrect.




      <severity>error</severity>
      <text>Unable to complete the requested operation due to: undefined method `exit_code' for #&lt;ResultIO:0x00000005d538d8&gt;.
Reference ID: 826de9c59bcb8a16c446439640200b3c</text>
      <exit-code>1</exit-code>
      <field nil="true"></field>

Comment 8 Clayton Coleman 2013-08-21 20:43:38 UTC
If the application is idled, a thread dump is technically not possible - so it's an error or a failure, not a 200.  But it seems like your changes are consistent so far.

Comment 9 Meng Bo 2013-10-15 05:45:58 UTC
Tested on devenv_3898, the error message returned is correct, but the exit code should not be 0.

  <messages>
    <message>
      <severity>error</severity>
      <text>Error occured while processing event 'thread-dump':Application is idle, must be started to allow a thread dump</text>
      <exit-code>0</exit-code>
      <field nil="true"></field>
      <index nil="true"></index>
    </message>
  </messages>

Comment 10 Lili Nader 2013-10-15 23:53:56 UTC
Assigning to runtime team exitcode returned from node is zero.

Comment 12 chunchen 2014-01-24 09:39:17 UTC
It's fixed, verified on devenv_4270, please refer to the following results:

1.Create jboss app
rhc app create jboss1 jbossas-7 
2.Idle the app
oo-admin-ctl-gears idlegear <uuid>
3.Threaddump the app

# rhc threaddump jboss1
Error occured while processing event 'thread-dump': Application is idle, must be started to allow a thread dump
# echo $?
1

By rest api:

  <messages>
    <message>
      <severity>error</severity>
      <text>Error occured while processing event 'thread-dump': Application is idle, must be started to allow a thread dump</text>
      <exit-code>1</exit-code>
      <field nil="true"></field>
      <index nil="true"></index>
    </message>
  </messages>


Note You need to log in before you can comment on or make changes to this bug.