[
https://issues.jboss.org/browse/WFLY-7797?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on WFLY-7797:
----------------------------------------
One possible thing to do here is to have the handlers for resource add and for
write-attribute for max-pool-size and derive-size all add a Stage.MODEL step to check for
the resource model having the combo of max-pool-size is defined and derive-size=NONE and
if found, just change the derive-size value to undefined.
Just dropping NONE as a legal value and removing it as a default value is a possibility as
well, but we'd have to add a ParameterCorrector such that if the user passed NONE it
would convert that to undefined before any validation occurred. The corrector is needed to
preserve compatibility. The runtime handler logic would need to account for the fact that
resolveModelAttribute may now return undefined.
The latter changes the management API but is probably better as it results in a more
straightforward behavior. The former is kind of voodoo behavior where a user-provided
setting is discarded.
Configuratin for ejb strict-max-pool is confusing regarding
derive-size and max-size
------------------------------------------------------------------------------------
Key: WFLY-7797
URL:
https://issues.jboss.org/browse/WFLY-7797
Project: WildFly
Issue Type: Enhancement
Components: EJB
Reporter: Wolf-Dieter Fink
Assignee: Brian Stansberry
Priority: Minor
Labels: ejb, management
The strict-max pool can be set for automatical configuration with
derive-size (none|from-worker-pools|from-cpu-count) or set the number of pool-entries by
use max-pool-size.
If derive-size is set the use of max-pool-size will throw an error during start that the
use is exclusive.
But as derive-size="none" mean the same as if the attribute is not set it will
be confusing.
- not clear what the pool size is then (I checked it is the default max-pool size =20)
- confusing if it is reset by cli, attr derive-size need to be removed to use max-size
So finally "none" is useless and should be removed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)