+++ This bug was initially created as a clone of Bug #831377 +++ Description of problem: The following configuration parameters are marked as long in the plugin descriptor but the AS7 accepts and returns decimal values. Attribute: retry-interval-multiplier Address: subsystem=messaging,hornetq-server=default,cluster-connection=my-cluster, name=my-cluster, parent=default How reproducible: Every time Steps to Reproduce: 1. Discover and import an AS7 server 2. Find the resource described by the address noted above. 3. Attempt to update the configuration with retry-interval-multiplier as a decimal number (eg 1.5) Actual results: The UI does not allow the user to submit a configuration update request with decimal numbers. If a decimal number is read from AS7, the user is asked to correct the entry. Expected results: Update retry-interval-multiplier with a decimal number without any problems. Additional info: The user are still able to update this resource with long values. --- Additional comment from snegrea on 2012-06-12 18:15:50 EDT --- Updated plugin descriptor to accept decimal values for retry-interval-multiplier.
release/jon3.1.x branch commit: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=3ea3c75618f4b1944ffd07a853b1df41b391642d
JON 3.1.1 ER1 build is available. Moving to ON_QA. https://brewweb.devel.redhat.com/buildinfo?buildID=226942
reopen. same situation as #835696
Please retest this. Bug 835696 received new code updates. This property update was not sent to the EAP6 server because of an earlier failure in the update process caused by bug 835696. No further code changes required for this bug.
Moving to ON_QA. The JON 3.1.1 ER3 build is available at https://brewweb.devel.redhat.com/buildinfo?buildID=230321.
same situation as 835696 . moving back to on_dev
Please test changing the value for the retry-interval-multiplier field in isolation as described in the description. The change is very specific to this particular field to accept decimal values. If the test fails please provide replication steps for failures. Also 835696 is related to the infinispan susbystem and not the messaging subsystem covered by this bug.
clean jon with only EAP plugin installed, started eap in full-ha mode, change of retry-interval-multiplier from 1 to 1.5 created server crash. reopened.
Please retest this. The underlying issue has been fixed. Update for this particular field were not broken but updates for the resource as a whole were not working properly. No changes required, other code changes resolved this issue.
The CR1 build is available at https://brewweb.devel.redhat.com/buildinfo?buildID=231258. Moving to ON_QA.
Created attachment 608443 [details] retryIntervalMultiplier_agent.log
Created attachment 608444 [details] retryIntervalMultiplier
reopen. Exception on gui during the edit, exception in log during the save - value gets back to 1.0
I was unable to reproduce this issue with the latest CR1 build. Version: 3.1.1.CR1 Build Number: 3219830:ad1ab7d More specifically I: - unpacked EAP 6.0.0.GA and started standalone with -c standalone-full-ha.xml - installed CR1 server and agent with plugin packs and imported eap instance - set connection properties for discovery, after successful discovery navigated to the specific resource and changed config Retry Interval Multiplier from 1 -> 1.5 successfully. - Navigated away from resource and back to verify reload successfully and double checked that value successfully persisted to as7 configuration as well. There were no related errors in agent log or exceptions in ui. Moving this back to ON_QA for another retest. If there is still an issue it may be helpful to try to delete the browser cache completely and try Shift + F5 to force browser refresh.
Tested with 3.1.1.CR1 version and it's working correctly for me as well.
Tested with 3.1.1.CR1 version and it's working correctly except for server reload - which is Bug 847869
verifying this bug. Case with reload invalid configuration still is visible, but since the value from 1 is being changed to smth like 1.5, this bug can be closed as verified and the bug#847869 is responsible for the case. Thanks Filip, Libor.
Bulk closing of old issues in VERIFIED state.