Red Hat Bugzilla – Bug 825384
[eap6] setting Keepalive Time when adding a new ThreadPool
Last modified: 2014-08-28 16:06:51 EDT
+++ This bug was initially created as a clone of Bug #824818 +++
Description of problem:When creating a new threadPool (or overall configuring Keepalive Time) It is not simple to guess Time unit. It would be nice if UI suggested time units by enumerating java.util.concurrent.TimeUnit. Moreover, Keepalive Time must be set, otherwise resource is not created. UI does not handle this.
Version-Release number of selected component (if applicable):
JON 3.1.ER4 EAP6.ER8
Steps to Reproduce:
1.have imported EAP6 in standalone mode
2.go to threads
3.add child of type 'ThreadPool'
Actual results: User is not required to set Keepalive Time, but it is required to create the resource. Time Unit is a text field and it is not straightforward to guess correct value
Expected results: UI notifies me, that Keepalive Time is required and pops-up a combo for selecting Unit.
This has now been fixed in release/jon3.1.x branch by the commits for bug 811288.
The commits relevant to this bug from release/jon3.1.x branch:
Tested on 3.1.1.ER1. There is no enumeration for Keepalive Time units and no Keepalive Time field validation (it is still possible to left the field empty).
The keepalive-time validation is complicated on the EAP6 side.
Here are the rules from the actual resource description:
1) The keepalive-time can be null
2) If either time or unit are non-null then both of them need to be non-null
Currently there is no support to implement the complex validation rules described by EAP6 without lists that support min and max. The support for min and max for lists has not been ported yet to JON 3.1.x branch and thus the complex validation cannot be implemented at this point.
However, these rules are not enforced by EAP6 (tested all the resources that have this property). Users can set either time or unit to null and the configuration is accepted by the server. Until the more complex solution is implemented given the weak enforcement from EAP6 side, all the required flags have been removed from the resource descriptor. This will avoid user confusion and prevent false configuration errors.
commit to release/jon3.1.x branch that removes required from keepalive-time field and subfields:
Moving to ON_QA. The JON 3.1.1 ER3 build is available at https://brewweb.devel.redhat.com/buildinfo?buildID=230321.
Tested on JON 3.1.1 CR1. keepalive-time is still required.
Followed this scenario:
1- Create a new thread pool in threads subsystem (right click on threads resource, create child->ThreadPool)
2- fill a 'new resource name' and 'Max Threads'. Leave keepalive time and keepalive units empty
create child operation failed with following error:
JBAS012472: Missing 'time' for parameter 'keepalive-time', rolled-back=true
When creating a new thread pool via eap cli the only required attributes are thread pool name and max threads. Thread pool is created successfully just with these two attributes.
For JON 3.1.1, the only fix was the removal of required flag from all keepalive-time fields to ease form validation and requirements to save the configuration.
To fix the situation reported in comment #6, the long term solution described in comment #3 (lists with min=0, max=1) should be applied. And this not available at this time in JON 3.1.1.
Both keepalive-time fields (time, unit) are still required (threadpool resource->configuration tab->clear 'keepalive time' field -> validation error message is displayed). According to rhq-configuration.xsd a default value for 'required' attribute is 'true' so commit from comment #4 actually didn't change value of 'required' attribute.
discussed with jshaugn and villiam.
summary: it's an issue. it's not related to the plugin. it's related to the UI. it's not blocking for JON 3.1.1. troubling that it is so reproducible (100%) for villiam ...and sporadic for others.
as a result ... i am setting the target release to jon 3.1.2
please disregard comment #9 ... that was for a completely different BZ and unrelated to this issue.
setting target release back to 3.1.1 to correct my error.
The target release was already set to 3.1.2 before comment #9. After chatting with Filip we will leave the target release to 3.1.2 since there is almost no change made in 3.1.1.
The default value of required attribute works differently for maps than for simple fields (see comment #8). A subfield of a map needs to explicitly have required=false in order to avoid validation after the initial set. So the before and after behaviour is unchanged in JON 3.1.1.
This bug is no longer valid since the thread configuration requires a keepalive-time in later EAP versions. For consistency, the keepalive-time will be kept as required accross all compatible versions of EAP. Without this correctly set, the resource would have unpredictible configuration based on defaults unknown to the user.
Closing this as NOTABUG, however dependent bugs noted in comments will be addressed independently.