Bug 584008
Summary: | EWS: Restart op appears to do nothing, but says success. | ||
---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Corey Welton <cwelton> |
Component: | Plugins | Assignee: | John Sanda <jsanda> |
Status: | CLOSED NOTABUG | QA Contact: | Corey Welton <cwelton> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 1.4 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: |
Solaris / EWS 1.0.1
|
|
Last Closed: | 2010-06-02 13:38:29 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 577051 |
Description
Corey Welton
2010-04-20 13:50:16 UTC
I performed several tests with tomcat6 using EWS 1.0.1 running on Fedora 12. I verified that the restart operation did in fact start a new tomcat process. I was also able to generate an exception in catalina.out that is similar to the one in the description. I created the port conflict by first starting an instance of EAP 5.0 then restarting tomcat via the restart resource operation. The operation reported having completed successfully. I looked further down in catalina.out and down past the exception it said that tomcat had started up successfully despite the port conflict. I have spent some time reviewing the plugin code and the restart operation as you might expect is implemented as stop followed by a start. If the process execution associated with the stop operation reports any errors, an exception is thrown that eventually gets propagated up the call stack and back to the server in the form of a PluginContainerException. In the event of an exception, the result of the restart operation should be reported as a failure. For the start operation, if the associated process execution reports any errors, they are logged on the agent. As a final step we check the resource availability. If the availability is down an exception is thrown which is propagated up the call stack. Corey can you provide with additional info including, * EWS version * which OS * Other apps that you had running * agent log * catalina.out * rhq server log Thanks The platform/server combination was Solaris / EWS 1.0.1. I am unsure what other apps might have been running on the system at this point. I will try to repro and see if this still occurs. This is with Corey to moving to ON_QA Confirmed this is still occurring on Solaris. * Got tomcat process id before sending restart op: root 20822 1 0 Apr 20 ? 8:00 /opt/java/jre1.6.0_14//bin/java -Dcom.sun.management.jmxremote.port=9003 -Dcom. * sent restart op and waited * Eventually op says it successfully completed * Got tomcat process id root 20822 1 0 Apr 20 ? 8:00 /opt/java/jre1.6.0_14//bin/java -Dcom.sun.management.jmxremote.port=9003 -Dcom. It looks like there was a port conflict for the com.sun.management.jmxremote.port property defined in /opt/redhat/ews/etc/sysconfig/tomcat6. I change that port and updating the connection properties in the RHQ server as well. When I tried a restart operation, I saw different pids. QA Closing. I am not sure whether we should be seeing a "success" message for a failed op, but this may percolating too far down in the system for it to really know that it has failed. |