Ok, the "per-cpu" option will go, which will break old configs who used it (unlikely.) Brian Stansberry 2:33 PM thread subsystem question... 2:34 PM The "count" and "per-cpu" notions David M. Lloyd 2:35 PM they should go away, they've been poo-pooed for EAP 6 Brian Stansberry 2:35 PM 1) do we want them 2) even if not, we can't get rid of them w/o breaking old configs David M. Lloyd 2:35 PM should just be count 2:35 PM well, we can just blame our own managers Brian Stansberry 2:35 PM ok, cool David M. Lloyd 2:35 PM I still like the per-cpu thing but apparently it's too confusing Brian Stansberry 2:36 PM I like the idea too, but not enough to spend any energy defending it David M. Lloyd 2:37 PM exactly Brian Stansberry 2:37 PM and I'm in a discussion where i'd have to defend it 2:38 PM so speak now or forever hold your peace! 2:38 PM David M. Lloyd holds his peace Brian Stansberry 2:38 PM gavel slams On 9/30/11 12:22 PM, ssilvert(a)redhat.com wrote: > I agree. The flatter representation is easier to understand. Do you need > a suffix at all? > > core-threads > queue-length > max-threads > > This is similar to the names we see in Tomcat connectors and everyone > understands. > > > Quoting Brian Stansberry <brian.stansberry(a)redhat.com&gt;: > >> Merged. http://github.com/jbossas/jboss-as/compare/d95cd7f...20e7427 >> >> There's some other work I want to do on this related to expressions >> support, but that shouldn't impact the management API except for the >> fact that some attributes/operations will support expressions. >> >> One thing where I'd like your input though is on some "complex >> attributes". If you look for uses of the method at [1] you'll see what >> I mean. They all deal with a complex attribute that represents an >> instance of the xsd type shown at [2]. >> >> I think we should look at those usages and see if we can flatten that >> complex attribute out into 2 simple attributes, e.g. >> >> core-threads-count >> core-threads-per-cpu >> >> queue-length-count >> queue-length-per-cpu >> >> max-threads-count >> max-threads-per-cpu >> >> The term "count" isn't so great in those attribute names though. Maybe >> "base" ?? >> >> [1] >> https://github.com/jbossas/jboss-as/blob/master/threads/src/main/java/org... >> >> >> >> [2] >> https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/... >> >> >> >> On 9/29/11 9:33 AM, Brian Stansberry wrote: >>> Alexey has a pull request in; I'll get it merged this morning. >>> >>> >>> On 9/29/11 8:38 AM, ssilvert(a)redhat.com wrote: >>>> What is the status? Is there enough there for me to get started on >>>> console support for the threading subsystem? >>>> >>>> Quoting Brian Stansberry <brian.stansberry(a)redhat.com&gt;: >>>> >>>>> On 9/28/11 4:38 PM, Alexey Loubyansky wrote: >>>>>> I'm flying to Ukraine tomorrow and actually will be on vacation >>>>>> until >>>>>> the 7th of Oct. But I'll be checking emails and looking what's going >>>>>> on. >>>>>> If anything, I'll be able to fix things. >>>>>> >>>>> >>>>> Ok, have a good trip! >>>>> >>>>>> What's missing (in my master) is support for expressions. Parsing is >>>>>> used only during the boot time, afaics. At run-time using >>>>>> expressions in >>>>>> write-attribute doesn't work. I actually am not sure whether it >>>>>> should >>>>>> at all but I'd expect it to. Anyway, I'm gonna look into this more. >>>>>> >>>>> >>>>> For it to work the client would have to send a node of >>>>> ModelType.EXPRESSION. >>>>> >>>>> Maybe we could do something with that in AttributeDefinition; e.g. if >>>>> the node is ModelType.STRING and expression is allowed, see if we can >>>>> it has ${...} and convert it. >>>>> >>>>>> Sorry again for being late, >>>>> >>>>> No worries; I was out sick Monday and have behind ever since. >>>>> >>>>> Thanks for taking this on! >>>>> >>>>>> Alexey >>>>>> >>>>>> On 09/27/2011 05:49 PM, Brian Stansberry wrote: >>>>>>> On 9/27/11 10:39 AM, Alexey Loubyansky wrote: >>>>>>>> On 09/27/2011 05:33 PM, Brian Stansberry wrote: >>>>>>>>> On 9/26/11 12:11 PM, Alexey Loubyansky wrote: >>>>>>>>>> I've re-written attributes registration, write handlers and add >>>>>>>>>> handler >>>>>>>>>> following the jms example. >>>>>>>>>> >>>>>>>>>> The problem I see (perhaps, I'm missing something) is that the >>>>>>>>>> default >>>>>>>>>> value, for e.g. priority for thread factory, which is -1, is not >>>>>>>>>> set on >>>>>>>>>> the factory instance during the add operation, if the priority >>>>>>>>>> value >>>>>>>>>> isn't provided by the user. But I do see >>>>>>>>>> AttributeDefinition.validateResolvedOperation and the default >>>>>>>>>> being >>>>>>>>>> set. >>>>>>>>>> Still read-attribute returns "undefined" with >>>>>>>>>> include-defaults=true. >>>>>>>>>> I'm >>>>>>>>>> gonna look further though. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I'll look at your pull request, as I'm not clear what the >>>>>>>>> issue is >>>>>>>>> and >>>>>>>>> maybe you've sorted it out? >>>>>>>> >>>>>>>> Yes, the default value is fixed now. Although, I discovered that >>>>>>>> invoking read-attribute on an attribute that has a default value >>>>>>>> on a >>>>>>>> node that doesn't exist works well and returns the default value. >>>>>>>> >>>>>>> >>>>>>> Thanks. https://issues.jboss.org/browse/AS7-1960 >>>>>>> >>>>>>>>>> Should I add system property replacement for all the attributes? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Generally, yes. Thread pool configs in general are a classic use >>>>>>>>> case >>>>>>>>> for expressions. If you see some attribute where it makes you >>>>>>>>> uncomfortable, then it's ok not to. For example, in the web >>>>>>>>> subsystem >>>>>>>>> >>>>>>>>> <connector socket-binding="http" .../> >>>>>>>>> >>>>>>>>> I don't like allowing an expression there as it's a ref to >>>>>>>>> another >>>>>>>>> part >>>>>>>>> of the model. Technically it could work, but it just makes me >>>>>>>>> uncomfortable and doesn't feel like a "must have." >>>>>>>>> >>>>>>>>> For any attribute we can always add the ability to use an >>>>>>>>> expression in >>>>>>>>> a later release, but we can't take it away. >>>>>>>> >>>>>>>> Expressions are not included in my pull request. I am looking at >>>>>>>> them >>>>>>>> now. And talked to Emanuel about them. EXPRESSION type is a bit >>>>>>>> confusing. I.e. it's not clear what the target type is, be it INT, >>>>>>>> STRING, etc, this info should be there in the attribute >>>>>>>> description. >>>>>>>> Just a flag allows-expressions would be good. Anyway, I'm looking >>>>>>>> into >>>>>>>> this now. >>>>>>>> >>>>>>> >>>>>>> If your attribute definition has the "allowExpression" property >>>>>>> set to >>>>>>> true, the generated metadata for the attribute or operation >>>>>>> parameter >>>>>>> will include "expressions-allowed" => true. >>>>>>> >>>>>>> The "type" => ModelType.XXX metadata will be whatever ModelType you >>>>>>> pass >>>>>>> into the AttributeDefinition, which should not be >>>>>>> ModelType.EXPRESSION; >>>>>>> it should be INT, STRING, whatever. >>>>>>> >>>>>>> The "parse" methods in SimpleAttributeDefinition are helpful -- >>>>>>> they >>>>>>> can >>>>>>> be called by the parser and will automatically detect >>>>>>> expressions in >>>>>>> the >>>>>>> string read from the parser and create a model node of >>>>>>> ModelType.EXPRESSION. >>>>>>> >>>>>>>>>> And "3) the various pools expose metrics; we need to add runtime >>>>>>>>>> attributes for those". Do they actually exist for threads? Or >>>>>>>>>> are >>>>>>>>>> they >>>>>>>>>> planned? I don't see them. >>>>>>>>>> >>>>>>>>> >>>>>>>>> org.jboss.threads.QueueExecutor, QueuelessExecutor, >>>>>>>>> JBossThreadPoolExecutor expose metrics. The MSC services we are >>>>>>>>> adding >>>>>>>>> (e.g. BoundedQueueThreadPoolService) return an ExecutorService >>>>>>>>> from >>>>>>>>> getValue() -- we may need to return a sub-interface that includes >>>>>>>>> the >>>>>>>>> metrics. >>>>>>>> >>>>>>>> I'll have a look, thanks. >>>>>>>> >>>>>>>> Alexey >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Software Engineer >>>>> JBoss by Red Hat >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat > > > > >