[jboss-as7-dev] [Detyped API Description] Example of multiple values for "allowed"?

Brian Stansberry brian.stansberry at redhat.com
Thu Sep 22 16:14:06 EDT 2011


On 9/22/11 2:45 AM, Thomas Diesler wrote:
> Yes, there are many config values that would require a restart of
> respective subsystems or services. This in turn would cause an yet
> undefined ripple to all the dependees.
>
> Also, it is possible that a subsystem cannot decide alone whether a
> write operation at runtime that would bounce a certain service is
> permissible. For example: Service A has property foo. Changing foo,
> requires A to restart. B depends on A. B cannot be restarted. Changing
> foo would hence require a server restart, which cannot be decided by
> looking at service A alone.
>
> I would suggest to be very selective of what can be changed at runtime
> and only allow write access through the management API to properties
> that are known to be safe.


Yeah, I agree, if "changed at runtime" means "restart a service to 
effect the change." See my recent response to Jaikiran on this thread; 
it's very hard to reason about whether it's safe to restart a service.

We do however, need to support changing pretty much every attribute via 
the management API. People should never be required to edit xml.

FYI, see "Applying Updates to Runtime Services" on [1] for more details 
on how things are currently meant to work. It's the "resource-services" 
case discussed there that IMO is most problematic. We currently only 
have one such case though.

[1]http://community.jboss.org/docs/DOC-16317


> Changes that require server restart can be
> collected and marked as such.
>


>
> On 09/21/2011 05:43 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 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.
>>
>> 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
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the jboss-as7-dev mailing list