Description of problem: The following thread pool configuration properties are missing/not exposed in JBoss ON: For Type: bounded-queue-thread-pool INT core-threads (nillable = true) INT queue-length (nillable = false) STRING handoff-executor (nillable = true) BOOLEAN allow-core-timeout (nillable = true) For Type: blocking-bounded-queue-thread-pool INT core-threads (nillable = true) INT queue-length (nillable = false) BOOLEAN allow-core-timeout (nillable = true) For Type: queueless-thread-pool STRING handoff-executor (nillable = true) Version-Release number of selected component (if applicable): 4.4.0.JON312GA How reproducible: Always Steps to Reproduce: 1. Create a thread pool for each type: bounded-queue-thread-pool, blocking-bounded-queue-thread-pool, and queueless-thread-pool. 2. Navigate to each thread pools configuration page Actual results: Unable to read/write the expected properties. Expected results: Able to specify all expected properties when creating thread pool from JBoss ON and able to read/write their values in the thread pools configuration page.
This should be fixed with commits to release/jon3.1.x: 5d670c32052 47ac8da386d The only way without significant changes to the plugin descriptor was to include all attributes for all templates. As before if the requested change could not be completed by the backend EAP instance then feedback would be reported in the child or configuration history. Larry can you verify that this addresses the issue that you reported?
Thread Pool creation/edit tested on EAP 6.0.0.GA and EAP 6.1.0.GA.
I think we still need a BZ to capture a more appropriate fix. At the moment, this fix is to introduce all possible configuration parameters for all thread pool types and let the user figure out which one are actually required or not based on the errors returned from EAP (trial and error). It seems a more appropriate fix is that templates should actual be "templates" and provide the necessary configuration parameters along with optional ones and suitable default values.
@Larry you are correct but this means adding several hundred more lines of plugin configuration(to an already massive plugin config) for each of 3 server types causing a good deal more duplication than we already have. I think this approach was initially looked at by Stefan and Heiko, but this whole issue gets at a much larger plugin design problem made worse by the shear number of properties in as7/eap6. Server startup bloat for 3.x is largely because of i)number of properties ii)plugin metadata definition. So I think this is a known issue for 3.3 and beyond any maybe even a bz already although I couldn't find it.
@Simeon, that is my point. We need a BZ to capture this specific problem. If there is one, then it should be updated to reflect what has been identified by this BZ and targeted to 3.3. If there isn't one, one should be created that captures the issue as you, Stefan and Heiko described. In the end, we can not hope that the user happens to discover the underlying resource error message that tells them they forgot to provide the required configuration parameters when creating a thread pool. I am also not advocating a whole new set of types/properties. My original suggestion was to make templates actual templates that specify the required configuration/parameters necessary for a specific configuration type. In this case, we would define all the available configuration parameters for a "thread pool". The template would then define which ones are required, displayed, and their default values based on the chosen template. The templates key would be the thread pool type property. If we don't want to use templates then we have no choice but to create some extra resource types (sub-types) which duplicate configuration. In either case, my expectation is that be captured as a 3.3 task and therefore would be documented as a known issue in 3.2 (i.e. logged against 3.2 with a target in the future).
Tested on Version: 3.2.0.ER4 Build Number: e413566:057b211 Started and imported EAP 6.1.0 standalone server to inventory. Navigated to threads->Inventory->Child Resources Created thread pools successfully : 1) New Resource Name: TestBoundedPool Resource Configuration Template: Bounded Queue Thread Pool Max Threads: 10 Keepalive Time: Time: 10 Unit: SECONDS Queue Length: 100 2) New Resource Name: TestBlockingBoundedQueuePool Resource Configuration Template: Blocking Bounded Queue Thread Pool Keepalive Time: Time: 10 Unit: SECONDS Queue Length: 100 Max Threads: 10 3) New Resource Name: TestQueuelessPool Resource Configuration Template: Queueless Thread Pool Keepalive Time: Unit: SECONDS Time: 10 Max Threads: 10 Navigated to the configuration tab and verified that the values are displayed correctly. However, on editing the thread pool created above is displaying error in the config history with failed status. Steps to reproduce: 1. Create a threadpool as above ( Example 3: with New Resource Name: TestQueuelessPool, Keepalive Time as 10 SECONDS and Max Threads 10) 2. Navigate to the 'Configuration->Current' tab of the threadpool. Edit 'Max Threads' value to some other value (Ex: 9 ) 3. Click on 'Save' button. The configuration History for the config change displays red status. Please refer the screenshot. 4. Click on the status in the configuration History. It shows the error details. {JBAS014653: Composite operation failed and was rolled back. Steps that failed:={Operation step-3=JBAS014792: Unknown attribute queue-length}}, rolled-back=true 5. Click on the Configuration History version link: It shows a red mark in 'Thread Pool Type' value. Howering the mark shows 'Field is required'. (Please refer the screenshot) No errors in server log.
Created attachment 817095 [details] ConfigChange_Status
Created attachment 817096 [details] ConfigChange_Version_Details
The obvious workaround for this issue is to delete the old resource and create with the new settings. Looking into the cause of this issue now.
This is fixed with commits to release/jon3.2.x and will be available in next brew build: 268806173a4f 99a8510f6a1f The fix was: i)better tune the attribute list parsing for templated resources. ii)mark the core-threads:expr attribute as a)'required' b)with 'defaultValue=0' to work around EAP server not accepting 'null' value for 'core-threads' even though the metadata for the same lists nillable=true. This functionality mirrors what the EAP 6.0/6.1 console functionality does when creating threadpools as well. Moving this to MODIFIED.
Moving this to ON_QA as it's available for re-testing with ER06.
One more commit for this fix: fc8729a683e1a483
When creating bounded-queue-thread-pool, even though I choose the correct configuration template, there is missing checking of queue-length being also required. Because it is in description, that is not such a big issue. But when I don't fill it and it fails, the error message gives [1] instead of [2], which is given by CLI command. When I also fill the queue-length, the resource creation fails nevertheless with the [1] error message [1] JBAS014746: unit may not be null, rolled-back=true [2] JBAS014746: queue-length may not be null, rolled-back=true
I have forgotten to mention, that I tested it with JON 3.2.0.ER6
Right ER6 was bogus specifically for this testing. The specific commits did not make it in. This needs to be tested with ER7. Moving back to MODIFIED and into ER7.
One more commit to revert the change to make core-threads attribute required with defaultValue=0. Committed to rc/jon3.2.0.ER6: aea2b50aed8c8 @Radim and @QE, because of https://bugzilla.redhat.com/show_bug.cgi?id=1033404, users will be unable to update Blocking Bounded Queue and Bounded Queue thread pools without to workaround listed in that BZ. The issue is an EAP6 issue, but JON will have a fix for that specific issue in JON 3.2.1.
Moving to ON_QA as available to test in ER7 and later brew builds.
Verified on Version : 3.2.0.ER7 Build Number : e8e6401:ff0061d Successfully created the threadpools using Resource Configuration Template. Updated the Queueless Thread Pool successfully. Updating the 'Blocking Bounded Queue' and 'Bounded Queue thread pool' is successfull after using the workaround listed in BZ#1033404. (While updating or creating the thread pool, enter core-threads attribute value of 0).