Bug 1033404
| Summary: | Updating Blocking Bounded Queue and Bounded Queue Thread Pools fails without core-threads value | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Operations Network | Reporter: | Simeon Pinder <spinder> | ||||||
| Component: | Plugin -- JBoss EAP 6 | Assignee: | Jay Shaughnessy <jshaughn> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Armine Hovsepyan <ahovsepy> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | JON 3.2 | CC: | ahovsepy, jshaughn, loleary, mfoley, myarboro, tsegismo | ||||||
| Target Milestone: | ER05 | ||||||||
| Target Release: | JON 3.3.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-12-11 13:59:26 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Simeon Pinder
2013-11-22 03:41:04 UTC
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
|