Bug 568764

Summary:	Connection Properties Caching
Product:	[Other] RHQ Project	Reporter:	dsteigne
Component:	Configuration	Assignee:	John Sanda <jsanda>
Status:	CLOSED WORKSFORME	QA Contact:	Sudhir D <sdharane>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.3.1	CC:	ian.springer, jsanda, tao
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-03-22 13:46:35 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:	574605

Description dsteigne 2010-02-26 15:03:15 UTC

Description of problem:
To reproduce:
1) Configure the 'Start script' property for a JBoss 5 EAP server.
2) Set the script prefix to some invalid setting (i.e. sudo instead of /usr/bin/sudo)
3) Goto operations invoke a 'Start Server' operation
4) This will fail due to the invalid script prefix
5) Fix the script prefix value
6) Initiate another 'Start Server' operation.

Expected result: Server starts normally

Actual result: Start server operation is still invalid since the invalid property is being used.  

The PluginConfiguration is correct on the CLI, so I assume that the server is maintaining cached version.  The server should always poll for the latest values prior to performing an operation.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 John Sanda 2010-03-20 02:39:25 UTC

So far I have not been able to reproduce this bug, but I am testing against the latest source which has changed considerably since the 2.3.1 release. I have an instance of EAP 5.0 and my agent running under a non-root/admin account.  In the connection properties I set the script prefix to /bin/foo/sudo which is non-existent file on my box. Then I submitted a startup operation. Not only was the operation reported as a success, but the JBoss instance did indeed start. I verified this by logging into the admin console.

Comment 2 John Sanda 2010-03-22 13:46:35 UTC

I have also tested with running both my agent and my EAP instance as root and was not able to reproduce. I am going to close as I cannot reproduce.

Comment 3 Ian Springer 2010-03-22 13:52:59 UTC

The following workarounds were reported to work:

A) Restart the agent.

B) Check the Unset box, saving and then editing with the correct value.