+++ This bug was initially created as a clone of Bug #847674 +++ Description of problem: When EAP server starts sending restart-required headers I am not able to reload it using UI. Version-Release number of selected component (if applicable): JON 3.1.1.ER1 + EAP6 GA How reproducible:always Steps to Reproduce: 1. Have EAP6 protected by user/pass running in standalone mode, imported with children => credentials are correct 2. make server require restart (for example by disabling ExampleDS datasource) 3. start 'reload' operation on server Actual results: Reload operation fails with this. org.rhq.core.pluginapi.inventory.InvalidPluginConfigurationException: Credentials for plugin to connect to AS7 management interface are invalid - update Connection Settings with valid credentials. at org.rhq.modules.plugins.jbossas7.ASConnection.handleAuthorizationFailureResponse(ASConnection.java:341) at org.rhq.modules.plugins.jbossas7.ASConnection.executeRaw(ASConnection.java:266) at org.rhq.modules.plugins.jbossas7.ASConnection.execute(ASConnection.java:433) at org.rhq.modules.plugins.jbossas7.ASConnection.execute(ASConnection.java:374) at org.rhq.modules.plugins.jbossas7.StandaloneASComponent.invokeOperation(StandaloneASComponent.java:100) at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source) Expected results: Additional info: Disabling a datasource is not the only way how to reproduce this BZ. It is enough to repeatedly run 'reload' operation on server, it fails for me on the 2nd attempt with above error message. --- Additional comment from snegrea on 2012-08-13 17:04:05 EDT --- The bug did not affect the restart operation itself. The plugin was not properly detecting when the server was up and operational after a successful restart. The code that was probing the server by sending an operation and looking for success or failure on the operation execution. If the server is not fully started, the operation execution could fail in surprising ways, thus throwing exceptions that bubbled up the stack. Updated the probing code to catch exceptions and just consider them failed attempts to connect to the server.
release/jon3.1.x branch commit: http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.1.x&id=33f5f3e4d9fe4ab9e75bf78add28eedf7db22be9
Moving to ON_QA since JON 3.1.1 ER2 build is availble - https://brewweb.devel.redhat.com/buildinfo?buildID=228250
This should not have been moved to ON_QA. It was changed to MODIFIED after the ER2 build. This change will be available in the ER3 build.
Moving to ON_QA. The JON 3.1.1 ER3 build is available at https://brewweb.devel.redhat.com/buildinfo?buildID=230321.
verified. the bug is only possible to reproduce if rhq management user is not correctly installed <-- which is not a valid case.
After a discussion with Stefan - reopening bug. Reproduction scenario is the following: Start EAP standalone - install rhq user (rhqadmin rhqadmin) - disable ExampleDS -> EAP restart operation -> EAP reload operation ---- > reload returns exception (screen-shot attached below). Restart operation works correctly, while reload fails. Scenario for having the original exception is: Start eap standalone -> install rhq user (rhqadmin rhqadmin) -> change rhq user password with some incorrect one -> EAP reload operation ------> original exception (the one mentioned in bug handleAuthorizationFailureResponse....) is being visible. <--- not valid scenario imho.
Created attachment 607354 [details] reloadExceptionGUI
Please retest. Updated all the wait methods for reload, shutdown, and restart to have the same design. All the methods now take into account possible exceptions for the test operation sent to the application server. Also, please make sure that two commands do not get scheduled simultaneously. For example, do not schedule restart and then without waiting for the restart to complete immediately schedule a reload. This is not a supported scenario. release/jon3.1.x branch commit: http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.1.x&id=91db63a06a0612349faf89678884b6b9150b411f
The CR1 build is available at https://brewweb.devel.redhat.com/buildinfo?buildID=231258. Moving to ON_QA.
verified on JON 3.1.1.CR1
reopen. Reproduction case: 1. Start eap standalone in full-ha mode. 2. Update cluster connection resource 3. Reload eap Screnshot attached No errors in all 3 (server, agent, eap) logs.
Created attachment 608439 [details] cridentials
Please use the reload and restart operations with valid server configurations. This bug captures errors with the reload and restart operation in normal working conditions. The invalid configuration problem is captured by bug 852891. For the purpose and testing of this bug please do not update resources that result in invalid configuration. If there are other resource the result in invalid configuration and thus the reload method and restart method do not work please attach the comments and logs to bug 852891.
Created attachment 608494 [details] credentials Changed cluster connection resource - retry Interval Multiplier from 1 to 1.5 - reloaded eap, exception is visible on gui. The value o retry interval multiplier is changed.
I was not able to reproduce this issue. On further analysis it looks like Comments 11, 12 and 14 were added to this BZ in error. This looks like the reproduce steps for 835701 and additionally this BZ was already set to verified by another QE member in comment 10. Moving this back to ON_QA and will ping ccrouch and mfoley to confirm or take another look at this.
it seems it's reproducible only in RHEL6 environment. My envs are: 1. RHEL6 - java version "jre-1.6.0-openjdk" 2. RHEL6 - java version "jre1.7.0" Libor was able to reproduce the bug on RHEl6 - see comment https://bugzilla.redhat.com/show_bug.cgi?id=835701#c16 Filips environement: Fedora 16 - jre-1.6.0-openjdk - bug is not reproducible at all.
Correct steps to reproduce: 1. Remove EAP from env. 2. Install new EAP 3. Start EAP (6) in standalone full-ha mode 4. Inventory EAP 5. Install RHQ user for EAP 6. Change the configuration of cluster connection/my cluster resource retry-interval-multiplier from 1 to 1.5 OR create a security domain resource and change it's cache type. 7. Reload EAP server Actual result: reload fails for only first time with exception. Expected result: no exception is visible in ui. Additional information: please get attached screen-shots - two different exceptions noticed jsut today.
since ordinary reload is fine, marking this bug as verified new bug #854310 for the first reload case is created.
Bulk closing of old issues in VERIFIED state.