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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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(a)redhat.com&gt; *To: *jboss-as7-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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&quot;&lt;jpai(a)redhat.com&gt; >> *To: *jboss-as7-dev(a)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(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > >> > _______________________________________________ >> > jboss-as7-dev mailing list >> > jboss-as7-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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&quot;&lt;jpai(a)redhat.com&gt; >>>> *To: *jboss-as7-dev(a)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(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> > >>>> > _______________________________________________ >>>> > jboss-as7-dev mailing list >>>> > jboss-as7-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

https://github.com/bstansberry/jboss-as/commit/9d2860dc6e397bb5964413a7ae... implements this approach. If this is the way you guys want to go; let me know and I'll push it.

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.

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&quot;&lt;jpai(a)redhat.com&gt; >>> *To: *jboss-as7-dev(a)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(a)lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> > >>> > _______________________________________________ >>> > jboss-as7-dev mailing list >>> > jboss-as7-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >