[
https://issues.redhat.com/browse/WFLY-13661?page=com.atlassian.jira.plugi...
]
Richard Achmatowicz updated WFLY-13661:
---------------------------------------
Description:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a
given type which can be used to handle incoming requests. Bean deployments can be
configured to use specific bean instance pools for the bean type, default bean instance
pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by
associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb)
with an existing bean instance pool from a bean-pool resource instance
<pools><bean-instance-pools><strict-max-pool> (e.g.
jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the
default pools need to be mapped somehow to specific bean pool resources defined in the
subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for
example) for each default bean instance pool and the attribute values would point to the
actual bean instance pool which backs that particular default pool.
However, the way that the configuration is currently set up to define the
default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for
default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values
cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the
<session-beans><stateless> elements, and these bean-instance-pool-ref elements
are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to
initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in
the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL,
DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource
definition, these attributes are registered, and whether they take a value or not is
*optional*
** these attributes have custom read-write handlers
EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL,
EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and
EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable =
model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable =
model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the
AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a
service representing the default SLSB and MDB pools if the default bean pool attributes
are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional
capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they
populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem
that there will always initially be default pools and so these conditional checks in the
add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL,
DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are
optional, they could be set to null by the user after the server boots up, resulting in no
default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required
and if so, how we can better set up the configuration of these pools. Also, the
DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could
be a bug as well.
was:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a
given type which can be used to handle incoming requests. Bean deployments can be
configured to use specific bean instance pools for the bean type, default bean instance
pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by
associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb)
with an existing bean instance pool from a bean-pool resource instance
<pools><bean-instance-pools><strict-max-pool> (e.g.
jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the
default pools need to be mapped somehow to specific bean pool resources defined in the
subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for
example) for each default bean instance pool and the attribute values would point to the
actual bean instance pool which backs that particular default pool.
The way that the configuration is currently set up to define the default-bean-pools is
confusing:
# XSD
** there are no attributes on the top level subsystem element for
default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values
cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the
<session-beans><stateless> elements, and these bean-instance-pool-ref elements
are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to
initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in
the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL,
DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource
definition, these attributes are registered, and whether they take a value or not is
*optional*
** these attributes have custom read-write handlers
EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL,
EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and
EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable =
model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable =
model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the
AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a
service representing the default SLSB and MDB pools if the default bean pool attributes
are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional
capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they
populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem
that there will always initially be default pools and so these conditional checks in the
add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL,
DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are
optional, they could be set to null by the user after the server boots up, resulting in no
default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required
and if so, how we can better set up the configuration of these pools. Also, the
DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could
be a bug as well.
Assignment of default bean instance pools for MDBs and SLSBs is
unclear
-----------------------------------------------------------------------
Key: WFLY-13661
URL:
https://issues.redhat.com/browse/WFLY-13661
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 20.0.1.Final
Reporter: Richard Achmatowicz
Assignee: Cheng Fang
Priority: Major
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a
given type which can be used to handle incoming requests. Bean deployments can be
configured to use specific bean instance pools for the bean type, default bean instance
pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by
associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb)
with an existing bean instance pool from a bean-pool resource instance
<pools><bean-instance-pools><strict-max-pool> (e.g.
jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the
default pools need to be mapped somehow to specific bean pool resources defined in the
subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for
example) for each default bean instance pool and the attribute values would point to the
actual bean instance pool which backs that particular default pool.
However, the way that the configuration is currently set up to define the
default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for
default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values
cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the
<session-beans><stateless> elements, and these bean-instance-pool-ref elements
are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to
initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in
the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL,
DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource
definition, these attributes are registered, and whether they take a value or not is
*optional*
** these attributes have custom read-write handlers
EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL,
EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and
EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable =
model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable =
model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the
AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a
service representing the default SLSB and MDB pools if the default bean pool attributes
are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional
capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they
populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem
that there will always initially be default pools and so these conditional checks in the
add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL,
DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are
optional, they could be set to null by the user after the server boots up, resulting in no
default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required
and if so, how we can better set up the configuration of these pools. Also, the
DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could
be a bug as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)