Bug 568764 - Connection Properties Caching
Summary: Connection Properties Caching
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: RHQ Project
Classification: Other
Component: Configuration
Version: 1.3.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: John Sanda
QA Contact: Sudhir D
URL:
Whiteboard:
Depends On:
Blocks: jon-sprint7-bugs
TreeView+ depends on / blocked
 
Reported: 2010-02-26 15:03 UTC by dsteigne
Modified: 2018-10-27 16:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-22 13:46:35 UTC
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.