[jboss-as7-dev] [Detyped API Description] Example of multiple values for "allowed"?
Carlo de Wolf
cdewolf at redhat.com
Thu Sep 22 12:56:16 EDT 2011
Ultimo the pool (or EJB) should never be bounced when changing something
like maxSize.
The implementation has to gracefully accept the new value.
Carlo
On 09/22/2011 04:23 PM, Brian Stansberry wrote:
> On 9/21/11 11:40 AM, Jaikiran Pai wrote:
>> On Wednesday 21 September 2011 09:13 PM, Brian Stansberry wrote:
>>> It's part of what I'm doing.
>>>
>>> I believe changes to these pool configs can't be applied directly to the
>>> runtime though, at least not without a header associated with the
>>> request indicating its ok to bounce the PoolConfigService. I presume
>>> bouncing that service will in turn bounce any EJB services that use that
>>> config. (If not, let me know, as it probably means we could just bounce
>>> it by default.)
>> The EJB component, upon construction, uses the PoolConfigService to
>> create a runtime representation of the pool. Once that runtime
>> representation is created, the EJB component no longer depends on the
>> PoolConfigService. For example, if there's a PoolConfig with max pool
>> size 20 and we use that for a SLSB, then we create a runtime pool
>> representation with a upper bound of 20. Any subsequent changes to that
>> PoolConfig (like changing the max pool size to 10) doesn't (and probably
>> shouldn't) affect the already functional EJB component.
>>
>> Any new EJB components created/deployed using the PoolConfig should
>> ofcourse use the new updated values of the PoolConfig while creating a
>> runtime representation of the pool.
>>
>> So I think, bouncing the PoolConfigService on write attribute operations
>> should be fine.
>>
> StatelessSessionComponentCreateService depends on PoolConfigService
> (non-optionally in some cases), and in turn the relevant
> ComponentStartService depends on it. So AIUI bouncing the PoolConfig
> service will bounce those and result in a new component being created
> and started. And the effect will cascade if any other services depend on
> StatelessSessionComponentCreateService or ComponentStartService.
>
>>> The StrictMaxPoolConfig stored in the PoolConfigService could be made
>>> mutable, in which case any EJB deployments deployed in the future would
>>> get the new config values, but any existing pools would remain as is.
>>> That seems like an unintuitive semantic for this particular use case though.
>>>
> Sounds like mutating the existing service is closer to the behavior you
> describe above.
>
>>> On 9/21/11 9:01 AM, Jaikiran Pai wrote:
>>>> That looks like a separate issue. The bean instance pool attributes have
>>>> currently been modelled as read-only. More of an oversight rather than
>>>> intentional.
>>>>
>>>> I think Brian is already working on
>>>> https://issues.jboss.org/browse/AS7-913 so this could be included as
>>>> part of that work. Else I'll take this up separately.
>>>>
>>>>
>>>> -Jaikiran
>>>> On Wednesday 21 September 2011 06:59 PM, Andrig Miller wrote:
>>>>> Why is it read-only? Seems like you should be able to set to a
>>>>> different value too. Another bug?
>>>>>
>>>>> Andy
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> *From: *"Jaikiran Pai"<jpai at redhat.com>
>>>>> *To: *jboss-as7-dev at lists.jboss.org
>>>>> *Sent: *Wednesday, September 21, 2011 4:39:34 AM
>>>>> *Subject: *Re: [jboss-as7-dev] [Detyped API Description] Example
>>>>> of multiple values for "allowed"?
>>>>>
>>>>> It's a bug. It should actually look like:
>>>>>
>>>>> "timeout-unit" => {
>>>>> "description" => "The instance acquisition
>>>>> timeout
>>>>> unit",
>>>>> "type" => STRING,
>>>>> "required" => false,
>>>>> "default" => "MINUTES",
>>>>> "allowed" => [
>>>>> "HOURS",
>>>>> "MINUTES",
>>>>> "SECONDS",
>>>>> "MILLISECONDS"
>>>>> ],
>>>>> "access-type" => "read-only",
>>>>> "storage" => "configuration"
>>>>> }
>>>>>
>>>>>
>>>>> I'll send a pull request with the fix.
>>>>>
>>>>> -Jaikiran
>>>>> On Wednesday 21 September 2011 04:02 PM, Jaikiran Pai wrote:
>>>>> > The model for EJB3 does allow more than one timeout unit type
>>>>> (SECONDS,
>>>>> > MINUTES and MILLISECONDS etc...). So that output doesn't look
>>>>> right. Let
>>>>> > me take a look why.
>>>>> >
>>>>> > -Jaikiran
>>>>> > On Wednesday 21 September 2011 03:53 PM, David Bosschaert wrote:
>>>>> >> Hi all,
>>>>> >>
>>>>> >> I'm looking at the EJB3 pools timeout-unit description, which
>>>>> is the
>>>>> >> following:
>>>>> >> "timeout-unit" => {
>>>>> >> "description" => "The instance acquisition timeout unit",
>>>>> >> "type" => STRING,
>>>>> >> "required" => false,
>>>>> >> "default" => "MINUTES",
>>>>> >> "allowed" => "MILLISECONDS",
>>>>> >> "access-type" => "read-only",
>>>>> >> "storage" => "configuration"
>>>>> >> }
>>>>> >>
>>>>> >> Is there an example of an attribute somewhere where 'allowed'
>>>>> has more
>>>>> >> than 1 value? I'd like to test a console gui piece against it.
>>>>> >>
>>>>> >> Thanks,
>>>>> >>
>>>>> >> David
>>>>> >> _______________________________________________
>>>>> >> jboss-as7-dev mailing list
>>>>> >> jboss-as7-dev at lists.jboss.org
>>>>> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>> >
>>>>> > _______________________________________________
>>>>> > jboss-as7-dev mailing list
>>>>> > jboss-as7-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
More information about the jboss-as7-dev
mailing list