Bug 997669 - Thread pools are missing their configuration parameters and therefore can not be properly managed
Thread pools are missing their configuration parameters and therefore can not...
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- JBoss EAP 6 (Show other bugs)
JON 3.1.2
Unspecified Unspecified
urgent Severity medium
: ER07
: JON 3.2.0
Assigned To: Simeon Pinder
Mike Foley
:
Depends On:
Blocks: 999125 1032841
  Show dependency treegraph
 
Reported: 2013-08-15 20:12 EDT by Larry O'Leary
Modified: 2014-01-02 15:38 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 999124 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ConfigChange_Status (78.97 KB, image/png)
2013-10-29 10:06 EDT, Sunil Kondkar
no flags Details
ConfigChange_Version_Details (135.99 KB, image/png)
2013-10-29 10:08 EDT, Sunil Kondkar
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 457493 None None None Never

  None (edit)
Description Larry O'Leary 2013-08-15 20:12:11 EDT
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.
Comment 2 Simeon Pinder 2013-09-09 23:09:49 EDT
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?
Comment 3 Simeon Pinder 2013-09-09 23:11:24 EDT
Thread Pool creation/edit tested on EAP 6.0.0.GA and EAP 6.1.0.GA.
Comment 4 Larry O'Leary 2013-09-25 16:01:03 EDT
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.
Comment 5 Simeon Pinder 2013-10-01 11:05:21 EDT
@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.
Comment 6 Larry O'Leary 2013-10-01 12:05:26 EDT
@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).
Comment 7 Sunil Kondkar 2013-10-29 10:04:37 EDT
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.
Comment 8 Sunil Kondkar 2013-10-29 10:06:54 EDT
Created attachment 817095 [details]
ConfigChange_Status
Comment 9 Sunil Kondkar 2013-10-29 10:08:05 EDT
Created attachment 817096 [details]
ConfigChange_Version_Details
Comment 10 Simeon Pinder 2013-11-11 15:05:44 EST
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.
Comment 11 Simeon Pinder 2013-11-15 10:31:46 EST
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.
Comment 12 Simeon Pinder 2013-11-19 10:56:51 EST
Moving this to ON_QA as it's available for re-testing with ER06.
Comment 13 Simeon Pinder 2013-11-20 22:18:02 EST
One more commit for this fix: fc8729a683e1a483
Comment 14 Radim Hatlapatka 2013-11-21 10:24:03 EST
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
Comment 15 Radim Hatlapatka 2013-11-21 10:24:57 EST
I have forgotten to mention, that I tested it with JON 3.2.0.ER6
Comment 16 Simeon Pinder 2013-11-21 10:32:44 EST
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.
Comment 17 Simeon Pinder 2013-11-21 23:59:38 EST
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.
Comment 18 Simeon Pinder 2013-11-22 00:01:47 EST
Moving to ON_QA as available to test in ER7 and later brew builds.
Comment 19 Sunil Kondkar 2013-11-28 07:15:47 EST
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).

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