Created attachment 666981 [details] output of the git push Description of problem: Application http://flirtinator-ferociousflirt.rhcloud.com/ reports The page isn't redirecting properly on Firefox Also, there is a message in the output of git push that is confusing: remote: Application is explicitly stopped! Use 'rhc app start -a jbossas-7' to start back up. How reproducible: Make a small change in the local files and do a git push Actual results: It appears to deploy fine except for the message to start the app and also that the appears is not there Expected results: The app to appear Additional info:
To add, looks like the application is idled and is failing to restart on git push. I tried reproducing with php-5.3 app but wasn't able to, so it could be specific to Jbossas-7? NOTE: We're idling apps after 2 days. This one doesn't seem to start up on first http request. Here's IRC discussion: [14:25] <m0smith> When I do a git push, this is one of the lines of output [14:25] <m0smith> remote: Application is explicitly stopped! Use 'rhc app start -a jbossas-7' to start back up. [14:27] <m0smith> rhc app show flirtinator --state [14:27] <m0smith> RESULT: [14:27] <m0smith> Geargroup jbossas-7 is idle [14:28] <m0smith> even thought rhc app start flirtinator returns started
Please refer to the details steps for reproducing this bug as below: Build: devenv_2618 rhc-1.3.2.gem Steps: 1. Create a jbossas app #rhc app create jbossas1 jbossas-7 -p xx 2. idle this app on instance #oo-idler -u uuid 3. Do some changes in local repo and git push 4. Try to visit this app via Browser Actual results: To step3: It's deployed fine but the final message is confusing as mentioned above. remote: Running .openshift/action_hooks/build remote: Running .openshift/action_hooks/deploy remote: hot_deploy_added=false remote: Application is explicitly stopped! Use 'rhc app start -a jbossas-7' to start back up. remote: Done remote: Running .openshift/action_hooks/post_deploy To ssh://189aaed28993492dba6997b8a0d7c188.rhcloud.com/~/git/jbosas1.git/ 17ac4f6..01fe695 master -> master To step4: The app can be redirected correctly, the changes take effect on the weg page. And the app status is changed to running automatically in this case.
Downgrading the severity. The message is indeed confusing, as it doesn't distinguish between user-stopped and idler-stopped states, even though the platform has the information to make such a distinction in the output. This will be addressed in a future release when the relevant cartridge start logic is pulled up into the platform and taken out of the cartridge scripts.
A quick addendum: Building an idled app won't restart it, by design. I suspect that the request made which apparently didn't restore the app right away was a dropped request at the beginning of the restore cycle before JBoss was capturing requests. Additionally, the "state" of the application being started in that case is expected. The state is set optimistically prior to actually starting the application, and represents the intended state. So, there may be a brief window of time where the app is "started" but still not servicing requests while it's actually starting up.
Feature added to upstream. The new cartridge API starts idled apps on build.