[jboss-as7-dev] "Scaled count" in thread pool configs

Thu Oct 6 20:33:44 EDT 2011

Apparently we've gotten feedback from management that the "scaled-count" 
notion in the jboss-as-threads-1_0.xsd[1] is confusing and should be 
replaced with a simple single attribute.

I planned to do this, but I see that the JCA subsystem has picked up 
this element type and incorporates it in their config.

I propose we eliminate this in JCA as well. We want consistency in how 
threads are configured across subsystems. The parser for a version 1_0 
document can just convert to a single value and log a WARN.

[1] 
https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-threads_1_0.xsd#L251

On 9/30/11 2:41 PM, Brian Stansberry wrote:
> 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 at 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 at redhat.com>:
>>
>>> 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/jboss/as/threads/ThreadsSubsystemThreadPoolOperationUtils.java#L143
>>>
>>>
>>>
>>> [2]
>>> https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-threads_1_0.xsd#L251
>>>
>>>
>>>
>>> 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 at 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 at redhat.com>:
>>>>>
>>>>>> 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
>>
>>
>>
>>
>>
>
>

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat