Description of problem: If you attempt to update Blocking Bounded Queue or Bounded Queue thread pool instances without specifying a value for core-threads, the update will fail with non-descriptive response. Version-Release number of selected component (if applicable): JON 3.2.0.GA How reproducible: Every time. Steps to Reproduce: 1. Import EAP 6.x instance into inventory and configure with valid connection settings. 2. Create Blocking Bounded Thread Pool instance without core-threads defined. 3. After successful creation, now attempt to update the same Thread pool instance again without setting a core-threads value. Actual results: Update fails. Expected results: Update should succeed. Additional info: Simple workaround is to apply add core-threads attribute value of 0 and the update succeeds.
Setting to ER04 for hopeful inclusion in 3.3.0, as time permits.
It's taken me a while to even get through the reproduction steps. There was a separate issue preventing creation if you didn't define the keepalive-time (I'll commit a fix for that shortly). After that I could reproduce. I think the issue may be in EAP, as the core-threads value can not be "unset", it basically must be set to an integer value and fails on null. This seems like a bug to me since to get the documented default it needs to be unset. The jboss CLI shows the same failure we are seeing. Because on create we don't even send the value, it initializes fine. But on update we need to be able to unset, in case a user had set a value and now wants to revert to the default behavior. I may be able to partially fix this by not unsetting if it's already unset. But this wouldn't solve the issue of trying to unset after a value has been set. I think I'll likely just open an EAP bug for this. I'll consider the partial fix and see how much work it is, then report back...
Moving into ER05 as didn't make the ER04 cut.
master commit e7a641350e155c7cd6ed6c566491ef425aeee3e2 Author: Jay Shaughnessy <jshaughn> Date: Mon Sep 29 14:53:21 2014 -0400 This is a partial fix for the reported issue, and contains two associated fixes for issues hit while working the issue. - First, The plugin descriptor needs to specify required="false" for the optional simples in a map of simples, otherwise they will be set to required="true" by default (I don't know if this is true for all props, it may be, but it was definitely true for the keepalive-time map-of-simples for AS7 ThreadPools). Otherwise values will be expected. Fix this because this prevents the create child from working unless you sepcify keepalive-time. - Second, a map-of-Simples in a resource configuration always generates a Map in the Configuration, even if the Map is "empty" because the Simples are all "unset" (set to null values). This was not being handled well in the create resource code, where an unset map should be ignored as if the entire PropertyMap is "unset". Note that an empty MapProperty in a configuration update should be processed, because we may be trying to unset one or more of Simples that currently have a value. - Third, to work around the fact that AS can't currently handle an undefine (i.e update to null) of core-threads (and possibly other attributes), add an optimization such that we don't try to update undefined (null) attributes to be undefined, since they are undefined already. - There was another issue in that the plugin code was actually modifying the ConfigurationDefinition held in the ResourceContext (which is a weakness in our design that we even let that happen). Changed to use a copy of the ConfigurationDefinition (and added a copy() method in the Entity, migrating it from plugin code where it was previously defined). So, the partial fix is that we can now create with empty maps and we can update without setting core-threads to a value, leaving it unset. But once set core-threads can *not* be unset until the AS bug is fixed and the fixed version is a version being managed. release/jon3.3.x commit 2c024accc57d27c86667fea238bb1be668f60f59 Author: Jay Shaughnessy <jshaughn> Date: Mon Sep 29 14:53:21 2014 -0400 (cherry picked from commit e7a641350e155c7cd6ed6c566491ef425aeee3e2) Signed-off-by: Jay Shaughnessy <jshaughn>
As an aside, this is the EAP bug I created for the inability to undefine core-threads once it has a value: https://bugzilla.redhat.com/show_bug.cgi?id=1147067 It's targeted for EAP 6.4 at this time.
Moving to ON_QA as available to test with the latest brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=394734
verified in JON 3.3 ER05 it is possible to create and edit 'blocking-bounded-queue-thread-pool' without providing 'core threads' count. screen-shots of created/edited resources added.
Created attachment 950112 [details] thread_pool_res
Created attachment 950113 [details] thread_pool_res_updated