Created attachment 628540 [details] Click the app name from "My Application" page. Description of problem: After I scaled up using rest api, before the scale operation finished, I tried to access the application details page, but caught code error. If I click the app name link from "My Application" page, it will return "LoadError in ApplicationsController#show" error. If I refresh the app details page directly, it will return "AsyncAware::ThreadTimedOut in Applications Controller#show" error. For the scale operation usually costs long time, I think we'd better try to deal with the above error to remind user. Version-Release number of selected component (if applicable): devenv_2340 How reproducible:always Steps to Reproduce: 1.Create a scalable application and do scale up/down using rest api 2.Before the scale operation finished, click the application name link to access the application details page 3.Before the scal operation finished, refresh the application page directly Actual results: After step 2, it will return "LoadError in ApplicationsController#show" error. After step 3, it will return "AsyncAware::ThreadTimedOut in Applications Controller#show" error. Expected results: We'd better to have remind message for user like "we are scaling.....". Additional info:
Created attachment 628551 [details] Refresh the application details page.
The REST API operation should not block the UI retrieving. It sounds like the calls to /cartridges and /gear_groups for the application are taking too long while a scale operation is going on, which is not acceptable (broker calls should return in <5s 99% of the time, <1s 95% of the time). Transferring to broker - Dan says there's a possibility (small) that the status check that gear_groups is doing is blocking on the node.
I checked and the gear groups app state isn't blocking. My guess is the system as a whole (running the site/broker/node scale up) was running slowly with all that going on. Only cure would be to make everything faster. I tried to recreate and I see app state is returned in well less than a second. I, [2013-01-26T21:35:40.979066 #21198] INFO -- : openshift.rb:736:in `execute_parallel_action' execute_par allel_action call / request = #<MCollective::RPC::Request:0x000000023daa48 @action="execute_parallel", @agent="openshift", @caller="uid=493", @data= {"domU-12-31-39-16-F8-29"=> [{:tag=>"", :gear=>"5104786b54cd909e0a000004", :job=> {:cartridge=>"openshift-origin-node", :action=>"app-state-show", ... I, [2013-01-26T21:35:40.979317 #21198] INFO -- : openshift.rb:225:in `oo_app_state_show' COMMAND: oo-app-state-show I, [2013-01-26T21:35:40.981764 #21198] INFO -- : openshift.rb:225:in `oo_app_state_show' COMMAND: oo-app-state-show I, [2013-01-26T21:35:40.984287 #21198] INFO -- : openshift.rb:789:in `execute_parallel_action' execute_parallel_action call - 10 [{:tag=>"", :gear=>"5104786b54cd909e0a000004", :job=>{:cartridge=>"openshift-origin-node", :action=>"app-state-show", :args=>{"--with-app-uuid"=>"5104786b54cd909e0a000004", "--with-container-uuid"=>"5104786b54cd909e0a000004"}}, :result_stdout=>"started", :result_stderr=>"", :result_exit_code=>0}, {:tag=>"", :gear=>"5104795454cd909e0a000056", :job=>{:cartridge=>"openshift-origin-node", :action=>"app-state-show", :args=>{"--with-app-uuid"=>"5104786b54cd909e0a000004", "--with-container-uuid"=>"5104795454cd909e0a000056"}}, :result_stdout=>"started", :result_stderr=>"", :result_exit_code=>0}] And I wasn't able to see the error. If you can recreate I would need to see the mcollective and broker logs to figure out what the slow part is. Passing back to the UI to see if they want to do anything.
Not yet ready to hack this around. We have discussed having a specific story to handle this in the console, but for the CLI we're just going to wait.